-
-
Notifications
You must be signed in to change notification settings - Fork 31k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve import time of various stdlib modules #118761
Comments
Sure! |
I've opened a PR over at the
@layday were you planning on tackling these?
This seems to be solved on main, |
importlib.metadata
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
This has been merged and released in version 8.4 of
I've submitted python/importlib_metadata#502 that defers zip import, and python/importlib_metadata#503 which defers |
(removing the 3.14 label since features always target the main branch) |
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Importing `pickle` is now roughly 25% faster. Importing the `re` module is no longer needed and thus `re` is no more implicitly exposed as `pickle.re`. --------- Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
@picnixz: I suggest to close this issue. |
…port The same change was made, and for the same reason, by argparse back in 2017. The textwrap module is only used when printing help text, so most invocations will never need it imported. See: python#1269 See: 8110837
gettext is often imported in programs that may not end up translating anything. In fact, the `struct` module already has a delayed import when parsing GNUTranslations to speed up the no .mo files case. The re module is also used in the same situation, but behind a function chain only called by GNUTranslations. cache the compiled regex globally the first time it is used. The finditer function can be converted to a method call on the compiled object (it always could) which is slightly more efficient and necessary for the conditional re import.
|
gettext is often imported in programs that may not end up translating anything. In fact, the `struct` module already has a delayed import when parsing GNUTranslations to speed up the no .mo files case. The re module is also used in the same situation, but behind a function chain only called by GNUTranslations. cache the compiled regex globally the first time it is used. The finditer function can be converted to a method call on the compiled object (it always could) which is slightly more efficient and necessary for the conditional re import.
…port The same change was made, and for the same reason, by argparse back in 2017. The textwrap module is only used when printing help text, so most invocations will never need it imported. See: python#1269 See: 8110837
gettext is often imported in programs that may not end up translating anything. In fact, the `struct` module already has a delayed import when parsing GNUTranslations to speed up the no .mo files case. The re module is also used in the same situation, but behind a function chain only called by GNUTranslations. cache the compiled regex globally the first time it is used. The finditer function can be converted to a method call on the compiled object (it always could) which is slightly more efficient and necessary for the conditional re import.
``gettext`` is often imported in programs that may not end up translating anything. In fact, the ``struct`` module already has a delayed import when parsing ``GNUTranslations`` to speed up the no ``.mo`` files case. The re module is also used in the same situation, but behind a function chain only called by ``GNUTranslations``. Cache the compiled regex globally the first time it is used. The finditer function is converted to a method call on the compiled object which is slightly more efficient, and necessary for the delayed re import.
The same change was made, and for the same reason, by ``argparse`` back in 2017. The ``textwrap`` module is only used when printing help text, so most invocations will never need it imported. Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
This reduces the import time of the `csv` module by up to five times, by importing `re` on demand. In particular, the `re` module is no more implicitly exposed as `csv.re`.
``gettext`` is often imported in programs that may not end up translating anything. In fact, the ``struct`` module already has a delayed import when parsing ``GNUTranslations`` to speed up the no ``.mo`` files case. The re module is also used in the same situation, but behind a function chain only called by ``GNUTranslations``. Cache the compiled regex globally the first time it is used. The finditer function is converted to a method call on the compiled object which is slightly more efficient, and necessary for the delayed re import.
The same change was made, and for the same reason, by ``argparse`` back in 2017. The ``textwrap`` module is only used when printing help text, so most invocations will never need it imported. Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
* subprocess: lazy import signal and locale to improve module import time
* subprocess: lazy import signal and locale to improve module import time (cherry picked from commit 49f2465) Co-authored-by: Taneli Hukkinen <3275109+hukkin@users.noreply.github.com>
* subprocess: lazy import signal and locale to improve module import time (cherry picked from commit 49f2465) Co-authored-by: Taneli Hukkinen <3275109+hukkin@users.noreply.github.com>
Feature or enhancement
Proposal:
Following on from #109653, further improvements can be made to import times.
Links to previous discussion of this feature:
https://discuss.python.org/t/deferred-computation-evalution-for-toplevels-imports-and-dataclasses/34173
For example:
importlib.metadata
is often used for tasks that need to happen at import, e.g. to enumerate/load entry point plug-ins, so it might be worth seeing if we can cut down its own import time a bit more.importlib.metadata
importszipfile
at the top for a function that won't be called in the vast majority of cases. It also importsimportlib.abc
, which in turn importsimportlib.resources
, to subclass an ABC with a single, non-abstract method - I assume redefining the method inimportlib.metadata
would be harmless. Some other less frequently-used imports which are only accessed once or twice, such asjson
, could also be tucked away in their calling functions.Linked PRs
pprint
#122725socket
by writingsocket.errorTab
as a constant and lazy import modules #121424mimetypes
#126979pickle
#128732re
import inbase64.b16decode
for a more efficient alternative #128736secrets
#128738csv
#128858tomllib
#128907pstats
andzipfile
by removing imports totyping
#128981sqlite3
#129118subprocess
#129427warnings
inthreading
#129428subprocess
(GH-129427) #129447subprocess
(GH-129427) #129448The text was updated successfully, but these errors were encountered: