Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork93
Defer import of zipp#502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
jaraco commentedSep 11, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I'm starting to feel like a frog being slowly boiled. I'm seeing repeated optimizations like this being handled piecemeal, and each time I do, I need to go through the same process: point out that there's a systemic problem that hasno solution, ensure there's a comment protecting the change and linking to the motivation, then merge and roll out the change. </rant> Looks good. I'll add the comment linking back to the motivation and analysis (here). Thanks for the contrib. |
Impoting zipp takes between 2-4 ms on my machine, which is at least 10% of overall import time of the
importlib_metadatapackage (depending on Python version). Since this package is only used in a single code path it makes sense to defer it.To estimate the cost of repeatedly calling
import zippI ran(this is with cpython main branch)
Since this is in a codepath that reads a zipfile from disk, this overhead is negligible.