Repository navigation
#127648 introduced a ~12% performance regression in python_startup_no_site benchmark #132952
Description
Activity
cc @srittau. I suppose this is because
iois imported at startup no matter what, and importingiois now slightly slower.Reacted by Raymond Hettingercc @srittau. I suppose this is because
iois imported at startup no matter what, and importingiois 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.
- added a commit that references this issue
on 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.That's a huge difference in startup time.
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.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.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:
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.If we want to speed this up further, I think this is the most promising parts are these:
import time: 601 | 601 | time import time: 209 | 810 | zipimport import time: 49 | 49 | _codecs import time: 535 | 583 | codecs import time: 400 | 400 | encodings.aliases import time: 608 | 1590 | encodings import time: 172 | 172 | encodings.utf_8zipimportseems 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.
Reacted by Adam Turner
Bug report
Bug description:
Plotting the Faster CPython team's weekly benchmarks, there is an obvious discontinuity in the python_startup_no_site benchmark:
This is between these two commits:
2025-03-03 0.98 b3c18bf
2025-03-08 0.85 a3990df
Bisecting over this range, it's reproducible that the first bad commit is c6dd2348ca.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs