You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In aiohttp we have a regression test for the import time of the library.
When using idna <=3.6, the test is passing, but with idna 3.7+ the test fails consistently, indicating a significant regression in import time.
Looking at the changes, the only obvious change is the massive amount of data added to idnadata.py (in joining_types). Maybe this could be lazy loaded, e.g. by putting the construction in a function with a @cache decorator, or by coming up with a more efficient data structure?
The text was updated successfully, but these errors were encountered:
Will look into improving the performance here, patches are welcome!
I haven't looked into it, but some of the odd data structures we use are informed by Jython and a 64kb limit it has on such structures, which I suspect he recent changes to joining_types also transgresses. Need to find a way to test if that is also affected as part of looking into this.
I have no idea what joining_types actually does, so don't have any obvious suggestions on how to improve the data structure. If you want to go with the lazy load function, I can take a look at that later. Should be pretty trivial.
In aiohttp we have a regression test for the import time of the library.
When using idna <=3.6, the test is passing, but with idna 3.7+ the test fails consistently, indicating a significant regression in import time.
Looking at the changes, the only obvious change is the massive amount of data added to idnadata.py (in joining_types). Maybe this could be lazy loaded, e.g. by putting the construction in a function with a
@cache
decorator, or by coming up with a more efficient data structure?The text was updated successfully, but these errors were encountered: