-
Notifications
You must be signed in to change notification settings - Fork 144
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
Python 3.12 runs much slower than Python 3.11 #1496
Comments
I suspect it's the large dict literal specifically that is the issue there. It sounds like in 3.12 it is reporting a debugger "line" event (which the debugger then has to process to check for breakpoints etc) for every subexpression in the literal, whereas before it was treated as a single atomic statement? If so, then this is to be expected - settrace-based Python debugging is inherently slow (~20x overhead per line of pure Python code, such as here). However, we're working on debugpy v2 utilizing the new sys.monitoring API in Python 3.12 for near-zero-overhead debugging; that should address this issue. And I think we should add this import as one of the test cases for that. |
@int19h it sounds like this will take a bit until it is ready. is there any quick fix/work-around for this? it also appears to affect spacy. |
I think the original issue has been fixed by emoji v2.10.1. For anyone working on this, here's another example:
import timeit
print(timeit.timeit("import colorcet", number=1)) Then run:
For me, this prints
Python 3.11 takes ~0.03s vs. 0.05s, so even without the debugger, Python 3.11 seems to be an order of magnitude faster. But the difference is much more striking with the debugger. Implementation is at https://github.com/holoviz/colorcet/blob/main/colorcet/__init__.py. I also opened holoviz/colorcet#121. |
Yes it was "solved" in emoji module by compressing the dict literal into a single line, previously the dict was spread over ~87k lines |
FYI for anyone considering this solution, unfortunately compressing the dict into a single line has created a new problem for us, it causes |
For the record, this issue (nedbat/coveragepy#1785) should be gone with Python 3.12.4 thanks to python/cpython#119118, so the practicality of one-line workarounds should be improved. That is relevant since the original issue continues to exist in Python 3.12.4 (long runtime importing large dicts with debugger attached) |
I have a similar problem with module python-opcua.
OS Linux (Debian 12) |
I've moved to pydevd. debugpy is unusable in Python 3.12, and I didn't want to go back to Python 3.11 |
Debugpy actually uses pydevd under the covers, but hasn't yet updated to pydevd's latest which has support for 3.12. |
I am currently debugging the repository langgenius/dify and am encountering a similar issue with the latest version, where the project takes an unusually long time to start (approximately 5 minutes) on my M1 Pro machine. I would like to understand the underlying cause of this delay and request guidance on how to resolve it. Environment Details:
Thank you for your assistance! Feel free to let me know if you would like any additional information. |
Sorry there's nothing you can do. We need to finish moving to the new 3.12 sys.monitoring support. |
Is there an approximate timetable for when we can start developing with vscode and devcontainer again? Since we are dependent on 3.12, vscode and devcontainer with the delays are unfortunately completely useless at the moment. That is not efficient working. |
All I can say is porting the Pydevd changes for 3.12 to debugpy are in progress. Can't say how long it will take though. |
This item: |
I'm pretty confident the pydev port will fix the performance issue. Here's the difference for me between the two with the With sys.monitoring
With sys.trace
|
Reopening, hasn't shipped yet. |
This issue should be fixed in the latest build of debugpy. It should ship with VS code in a future version of the Python Debugger Extension or you can install your own debugpy from pypi |
Wow. 1.8.6 goes from 24s to 4s launching my app with debugger attached. Great work! I see this has made its way into https://github.com/microsoft/vscode-python-debugger already via microsoft/vscode-python-debugger@afd0d2b. Until that is released, this is how I was able to update the bundled
|
Environment data
Actual behavior
Importing the emoji module (v2.10.0) with debugging enabled takes a long time with Python 3.12 compared to Python 3.11.
When running from VS Code with the default debug configuration via
F5
, the import takes 4 minutes on Python 3.12 but only 50ms on Python 3.11The emoji module contains a large Python file, here. I suspect the slow debugging has something to do with this file.
Expected behavior
Similar run times in Python 3.11 and Python 3.12
Steps to reproduce:
pip install emoji==2.10.0
F5
The text was updated successfully, but these errors were encountered: