-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Performance regression in regr_test.py
#11590
Comments
Here's the first run that used Python 3.12: And here's the one immediately before that, which used Python 3.11: https://github.com/python/typeshed/actions/runs/8206219736/job/22444819614?pr=11524 |
I see something similar if I try this locally on linux:
I emptied the mypy cache beforehand each time. Is this some issue with mypy and Python 3.12? I'm fine with using 3.11 in CI for now, although we should add a comment explaining the situation. |
I haven't investigated really yet (and probably won't have time until this evening at the earliest), but here's a few hypotheses I can think of:
It would be good to get to the bottom of things anyway -- if it's mypy, CPython or uv to blame, I'd be interested in letting them know. |
On my machine there's about a 10s difference consistently. I didn't think to clear mypy cache so take this with a grain of salt (and I've got other things to do today). But hopefully this offers some pointers. Some mypy subprocess runs can differ up to 2s, mostly slower on Python 3.12, but not always, so it could average out over the 255 subprocess calls (so I'll refrain from posting my mypy subprocesses timing results for now) Note that the install command with uv has a clear performance difference though. At least on my machine. (as Alex mentionned, could be caused by the installed library's Python 3.12 version, not necessarily a problem in vu itself) Python 3.11 Checking uv subprocess commands with perf_counter
Some preliminary cprofile results
Python 3.12 Checking uv subprocess ommands with perf_counter
Some preliminary cprofile results (look at those primitive calls!!!)
|
I looks like running
regr_test.py
on Python 3.12 in CI, rather than Python 3.11, makes the job take 20-30s longer. It used to take between 3m and 3m10s; now it takes between 3m30s and 3m40s. That's actually pretty noticeable on PRs like #11585, #11587 or #11589, where we don't runmypy_primer
, meaning thatregr_test.py
is the slowest job in CI for those PRs.It seems good generally for us to run this job on the latest version of Python, so I'm not necessarily suggesting that we should go back to running it on Python 3.11. But I'm curious if anybody has any ideas as to why bumping the Python version would make the job slower in CI. (I've experimented on my local fork with changing it back to using 3.11, and it fixes the performance regression -- it was definitely caused by #11544, unfortunately.)
The text was updated successfully, but these errors were encountered: