Skip to content
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

Open
layday opened this issue May 8, 2024 · 17 comments
Open

Improve import time of various stdlib modules #118761

layday opened this issue May 8, 2024 · 17 comments
Labels
performance Performance or resource usage topic-importlib type-feature A feature request or enhancement

Comments

@layday
Copy link

layday commented May 8, 2024

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 imports zipfile at the top for a function that won't be called in the vast majority of cases. It also imports importlib.abc, which in turn imports importlib.resources, to subclass an ABC with a single, non-abstract method - I assume redefining the method in importlib.metadata would be harmless. Some other less frequently-used imports which are only accessed once or twice, such as json, could also be tucked away in their calling functions.

Linked PRs

@AlexWaygood AlexWaygood added topic-importlib performance Performance or resource usage type-feature A feature request or enhancement labels May 8, 2024
@hugovk
Copy link
Member

hugovk commented Aug 5, 2024

@layday Is it okay if I repurpose this issue as an "Improve import time of various stdlib modules" like #109653 but for 3.14?

I've got some pprint improvements, and if we have importlib.metadata and some others, we can group them under the same umbrella issue like last time.

@layday
Copy link
Author

layday commented Aug 5, 2024

Sure!

@danielhollas
Copy link
Contributor

danielhollas commented Aug 6, 2024

I've opened a PR over at the importlib_metadata repo that avoids importing inspect. python/importlib_metadata#499

importlib.metadata imports zipfile at the top for a function that won't be called in the vast majority of cases.
Some other less frequently-used imports which are only accessed once or twice, such as json, could also be tucked away in their calling functions.

@layday were you planning on tackling these?

It also imports importlib.abc, which in turn imports importlib.resources, to subclass an ABC with a single, non-abstract method

This seems to be solved on main, importlib.abc no longer imports importlib.resources.

@hugovk hugovk changed the title Further improve import time of importlib.metadata Improve import time of various stdlib modules Aug 6, 2024
@hugovk hugovk added the 3.14 new features, bugs and security fixes label Aug 6, 2024
hugovk added a commit that referenced this issue Aug 7, 2024
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
blhsing pushed a commit to blhsing/cpython that referenced this issue Aug 22, 2024
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
@danielhollas
Copy link
Contributor

I've opened a PR over at the importlib_metadata repo that avoids importing inspect. python/importlib_metadata#499

This has been merged and released in version 8.4 of importlib_metadata 🎉

importlib.metadata imports zipfile at the top for a function that won't be called in the vast majority of cases. It also imports importlib.abc, which in turn imports importlib.resources, to subclass an ABC with a single, non-abstract method - I assume redefining the method in importlib.metadata would be harmless. Some other less frequently-used imports which are only accessed once or twice, such as json, could also be tucked away in their calling functions.

I've submitted python/importlib_metadata#502 that defers zip import, and python/importlib_metadata#503 which defers json and platform.

@picnixz picnixz removed the 3.14 new features, bugs and security fixes label Aug 31, 2024
@picnixz
Copy link
Member

picnixz commented Aug 31, 2024

(removing the 3.14 label since features always target the main branch)

barneygale pushed a commit that referenced this issue Sep 1, 2024
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>
@hugovk
Copy link
Member

hugovk commented Jan 7, 2025

Note for when documenting this in What's New in Python 3.14, can also include #128559 / #128560.

ebonnal pushed a commit to ebonnal/cpython that referenced this issue Jan 12, 2025
picnixz added a commit that referenced this issue Jan 14, 2025
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>
@vstinner
Copy link
Member

@picnixz: I suggest to close this issue.

eli-schwartz added a commit to eli-schwartz/cpython that referenced this issue Jan 16, 2025
…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
eli-schwartz added a commit to eli-schwartz/cpython that referenced this issue Jan 16, 2025
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.
@hukkin
Copy link
Contributor

hukkin commented Jan 16, 2025

@picnixz here's the tomllib import time improvements from Tomli! #128907

@hugovk
Copy link
Member

hugovk commented Jan 16, 2025

enum has improved a lot recently, here's python3.12 -X importtime -c 'import enum' && tuna import.log and for 3.13 and 3.14 (using latest releases on macOS) visualised with https://github.com/nschloe/tuna:

Image Image Image

eli-schwartz added a commit to eli-schwartz/cpython that referenced this issue Jan 17, 2025
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.
eli-schwartz added a commit to eli-schwartz/cpython that referenced this issue Jan 17, 2025
…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
gpshead pushed a commit that referenced this issue Jan 17, 2025
Improve import time of `tomllib`  (in sync with upstream)
picnixz added a commit that referenced this issue Jan 18, 2025
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`.
eli-schwartz added a commit to eli-schwartz/cpython that referenced this issue Jan 19, 2025
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.
AA-Turner pushed a commit that referenced this issue Jan 20, 2025
``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.
AA-Turner added a commit that referenced this issue Jan 20, 2025
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>
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this issue Jan 21, 2025
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`.
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this issue Jan 21, 2025
``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.
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this issue Jan 21, 2025
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>
picnixz added a commit that referenced this issue Jan 23, 2025
Importing `pstats` or `zipfile` is now roughly 20% faster.

This is achieved by removing type annotations depending on `typing`.
gpshead pushed a commit that referenced this issue Jan 29, 2025
* subprocess: lazy import signal and locale to improve module import time
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 29, 2025
* 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>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 29, 2025
* 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>
gpshead pushed a commit that referenced this issue Jan 29, 2025
…29448)

gh-118761: Improve import time of `subprocess` (GH-129427)

* 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>
gpshead pushed a commit that referenced this issue Jan 29, 2025
…29447)

gh-118761: Improve import time of `subprocess` (GH-129427)

* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Performance or resource usage topic-importlib type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

7 participants