Open ptgolden opened 1 week ago
While investigating https://github.com/monarch-initiative/monarch-app/issues/819, I noticed a bottleneck in loading the "merged" context in these lines in curie:
https://github.com/biopragmatics/curies/blob/47d1f22e3aba42ea365cd7e99403eacfede4af5a/src/curies/api.py#L527-L533
Is it necessary to check for duplicate prefixes on known-good prefix maps (i.e. those bundled with this package)? If not, the converter loaded here:
https://github.com/linkml/prefixmaps/blob/c61e812f6de398daf388b996f6dbb691f93addac/src/prefixmaps/io/parser.py#L30-L31
can be initialized with strict=False, resulting in a speedup of about ~15s on the "merged" context. I am happy to create a PR if that sounds okay.
strict=False
To be clear, strict=False would be added as a keyword to the .from_extended_prefix_map method here:
.from_extended_prefix_map
https://github.com/linkml/prefixmaps/blob/c61e812f6de398daf388b996f6dbb691f93addac/src/prefixmaps/datamodel/context.py#L379-L386
While investigating https://github.com/monarch-initiative/monarch-app/issues/819, I noticed a bottleneck in loading the "merged" context in these lines in curie:
https://github.com/biopragmatics/curies/blob/47d1f22e3aba42ea365cd7e99403eacfede4af5a/src/curies/api.py#L527-L533
Is it necessary to check for duplicate prefixes on known-good prefix maps (i.e. those bundled with this package)? If not, the converter loaded here:
https://github.com/linkml/prefixmaps/blob/c61e812f6de398daf388b996f6dbb691f93addac/src/prefixmaps/io/parser.py#L30-L31
can be initialized with
strict=False
, resulting in a speedup of about ~15s on the "merged" context. I am happy to create a PR if that sounds okay.