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
{{ message }}
Repository navigation
#127648 introduced a ~12% performance regression in python_startup_no_site benchmark #132952
cc @srittau. I suppose this is because io is imported at startup no matter what, and importing io is now slightly slower.
Yes, that's the gist of it. I'm surprised by the size of the regression -- I think that's a testament to how close to the lower limit Python startup already is.
It looks like we need io at startup (in pylifecycle.c) only in order to access io.open and io.TextIOWrapper, both of which come from the private _io module, so we could speed up startup by importing from _io instead: #132957. Not completely sure it's worth it, but it's a very simple change.
It looks like we need io at startup (in pylifecycle.c) only in order to access io.open and io.TextIOWrapper, both of which come from the private _io module, so we could speed up startup by importing from _io instead: #132957. Not completely sure it's worth it, but it's a very simple change.
This sounds worthwhile to me, independent from this regression. Importing a Python-only module will most likely always incur a fairly large performance penalty.
We could also implement the pseudo-protocols in C if that helps with performance. Finally, we could go back to the original plan to move the protocols to typing, although they are better placed in io.
@mdboom For my understanding: This is only for the python_startup_no_site benchmark? Is there a significant slowdown for "normal" Python startup benchmark?
I think this regresssion is primarily from adding the _collections_abc import, and that module gets imported anyway when site.py is used (because os.py imports it). _collections_abc is relatively slow. The startup with site would also get slightly slower from adding two more classes defined at startup, but that's fast enough that it's probably not easily detectable.
zipimport seems like it should only be needed if we actually use ZIP imports, which many programs won't. Maybe we can defer importing it until we need it?
For encodings, many programs will only ever need UTF-8, not the whole registry system. It looks like this gets triggered by _PyUnicode_InitEncodings, which first initiates the codec registry (triggering import encodings) and then sets up the default encoding (usually UTF-8). Perhaps there can be a fast path where we only register UTF-8 and defer registering the others until we need them.
This is not really part of this issue since it's not a regression, but leaving this here in case there's interest in speeding up startup further.
Activity
JelleZijlstra commentedon Apr 25, 2025
cc @srittau. I suppose this is because
iois imported at startup no matter what, and importingiois now slightly slower.mdboom commentedon Apr 25, 2025
Yes, that's the gist of it. I'm surprised by the size of the regression -- I think that's a testament to how close to the lower limit Python startup already is.
pythongh-132952: Import _io instead of io at startup
JelleZijlstra commentedon Apr 25, 2025
It looks like we need
ioat startup (inpylifecycle.c) only in order to accessio.openandio.TextIOWrapper, both of which come from the private_iomodule, so we could speed up startup by importing from_ioinstead: #132957. Not completely sure it's worth it, but it's a very simple change.srittau commentedon Apr 25, 2025
That's a huge difference in startup time.
This sounds worthwhile to me, independent from this regression. Importing a Python-only module will most likely always incur a fairly large performance penalty.
We could also implement the pseudo-protocols in C if that helps with performance. Finally, we could go back to the original plan to move the protocols to
typing, although they are better placed inio.srittau commentedon Apr 28, 2025
@mdboom For my understanding: This is only for the
python_startup_no_sitebenchmark? Is there a significant slowdown for "normal" Python startup benchmark?mdboom commentedon Apr 28, 2025
Yes, there is also a slowdown for
python_startup, but not so cleanly for a single commit like this, it's more death by a thousand papercuts:JelleZijlstra commentedon Apr 28, 2025
I think this regresssion is primarily from adding the
_collections_abcimport, and that module gets imported anyway whensite.pyis used (becauseos.pyimports it)._collections_abcis relatively slow. The startup withsitewould also get slightly slower from adding two more classes defined at startup, but that's fast enough that it's probably not easily detectable.JelleZijlstra commentedon Apr 28, 2025
If we want to speed this up further, I think this is the most promising parts are these:
zipimportseems like it should only be needed if we actually use ZIP imports, which many programs won't. Maybe we can defer importing it until we need it?For
encodings, many programs will only ever need UTF-8, not the whole registry system. It looks like this gets triggered by_PyUnicode_InitEncodings, which first initiates the codec registry (triggeringimport encodings) and then sets up the default encoding (usually UTF-8). Perhaps there can be a fast path where we only register UTF-8 and defer registering the others until we need them.This is not really part of this issue since it's not a regression, but leaving this here in case there's interest in speeding up startup further.
gh-132952: Speed up startup by importing _io instead of io (#132957)