Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Improve import time #326

Open
Open
@Sachaa-Thanasius

Description

@Sachaa-Thanasius

importlib_resources currently takes a while to import. From rough local testing with whatever Python versions I have installed, the figures are something like this:

OSPython ImplementationPython Version(s)Import Time (ms)
Windows 10CPython3.9-3.13~27-37
Windows 10PyPy3.10~89
WSL 2CPython3.9-3.13~8.5-12.5

(The numbers were obtained by cloning the main branch and running<python> -m timeit -n 1 -r 1 -- "import importlib_resources" a bunch without a venv, just raw import without site-packages baggage. If need be, I can get more precise results.)

For context on my perspective, most of the standard library modules that I've interacted with take a fraction of that time.

To improve this, I've been messing about and managed to get the figures down by at least7x:

OSPython ImplementationPython Version(s)Import Time (ms)
Windows 10CPython3.9-3.13~3.5-6.5
Windows 10PyPy3.10~5.5
WSL 2CPython3.9-3.13~0.6-1.5

This improvement mostly comes from the following:

  1. Replacing theinspect usage with a cheaper pattern that other stdlib modules use.
  2. Isolating typing-related symbols and annotations-related symbols so that they are only imported when deferred annotations using them are evaluated (with e.g.inspect.get_annotations ortyping.get_type_hints).
  3. Isolating less-used but very expensive modules/submodules such that they are only imported on demand, i.e. only when deferred annotations containing them are evaluated or functions using them are called.
  4. Consolidating small submodules to avoid reading and compiling several extra files (also, it makes the structure more likeimportlib_metadata's, imo).

That's all without a few tricks employed by other standard library modules likeimportlib._bootstrap andimportlib.util, e.g. avoiding importingfunctools andcontextlib in exchange for slightly more verbose code. Doing those would make the improvement at least10x.

Considering this is a "foundational" library (meant to partially replace the widely usedpkg_resources) and is also in the standard library, and the potential for improvement is so large with a pretty small amount of effort, I was wondering if there would be interest in improving this, and if so, whether it would be acceptable for me to attempt that by upstreaming some of my work?

P.S. The branch I've been experimenting on ishere if you're curious, though it does too many things (e.g. fixes some bugs, completes the typing, adds unnecessary personalization) for me to consider making a PR with it directly. Makes more sense to do things piecemeal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp