Import time improvements

[djrobstep]

I would like to improve the time this package takes to import. Would you be happy to receive PRs with improvements?

[jkowalleck]

whats your idea on improving the import time?
HOW would this be implemented?

[djrobstep]

I tried just now adding a __getattr__ to create the syntax validators lazily on access rather than on import - quite straightforward, and about an 80% reduction in import time.

On my machine the import time goes from:

import time:    386566 |     446498 |   rfc3987_syntax.syntax_helpers
import time:       240 |     446738 | rfc3987_syntax
python -X importtime -c 'import rfc3987_syntax'  0.44s user 0.03s system 90% cpu 0.518 total

to:

import time:     22951 |      56741 |   rfc3987_syntax.syntax_helpers
import time:       130 |      56870 | rfc3987_syntax
python -X importtime -c 'import rfc3987_syntax'  0.07s user 0.01s system 86% cpu 0.093 total

[djrobstep]

I will put up a PR shortly

[jkowalleck]

the underlying parser generator is capable of producing a standalone parser which can be shipped.

why generate the parser on load anyway? lets utilize this feature instead.

[djrobstep]

Sure thing, although sounds like a bigger piece of work than this lazy attribute access, which should solve the problem in the short term.

Anyway PR here: #8

[paugier]

I also see a very large import time (~ 0.5 s) which is disturbing.

Laziness (with something like #8) would be useful.

But I also agree with @jkowalleck than all these quite expensive Lark(...) calls tend to indicate that it would be nice to save these results in the package. I see https://lark-parser.readthedocs.io/en/stable/examples/index.html#standalone-example. I don't know if this could be use to improve startup time in the case rfc3987-syntax is really use.

[erezsh]

There are several things that could be done to improve the parser speed -

1. Switch from Earley to LALR. Unless the grammar has unavoidable ambiguities, it should be possible. (making it "standalone" doesn't matter much for speed)

2. Make the ipv4 and ipv6 rules into regexes instead. While having it as a rule is more readable, a regex will be much faster. (especially if you stay with Earley)

[jkowalleck]

Switch from Earley to LALR. Unless the grammar has unavoidable ambiguities, it should be possible. (

tried this without success. the spec's grammar is just not good for LALR.

Make the ipv4 and ipv6 rules into regexes instead.

before moving to regex, we should get the IPv4 rules right according to spec - #4

[ryanbordo]

Does this contribution from @agentydragon address?
#11

[paugier]

It seems to be a very nice improvement. However, it seems to me that it would be good to adapt #8 to also get laziness, i.e. to improve the import time when syntax_parser is not used at all.

[ryanbordo]

Fair enough. Would happy to see these both merged and would be willing to help out

[zibertscrem]

Hey, I also been very pissed off by the performance of the module loading and brought my own PR for it #14 (also, lazy loading). So, pick whatever you like more

I've tested mine on the real env through airflow which uses jsonschema which uses this lib

I'm kind of curious if this issue even going to be resolved cause currently I see that our guy (author of the lib) had no visible contributions to GH since middle of 2025

[jkowalleck]

this has been solved in maintained fork of the library since version 1.3.0

• https://pypi.org/project/rfc3987-syntax2/
• https://github.com/jkowalleck/rfc3987-syntax2/releases/tag/v1.3.0