Skip to content
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

Closed
cvzi opened this issue Jan 19, 2024 · 18 comments · Fixed by #1680
Closed

Python 3.12 runs much slower than Python 3.11 #1496

cvzi opened this issue Jan 19, 2024 · 18 comments · Fixed by #1680

Comments

@cvzi
Copy link

cvzi commented Jan 19, 2024

Environment data

  • debugpy version: 1.8.0
  • OS and version: Windows 10
  • Python version: 3.12 64bit
  • Using VS Code

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.11

The 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:

  1. Install emoji module: pip install emoji==2.10.0
  2. Create a test file in VS Code that imports the emoji module:
    import time
    start = time.time()
    
    import emoji
    
    end = time.time()
    print("import time", end - start)
  3. Set VS Code to Python 3.12
  4. Run in VS Code by pressing F5
@int19h
Copy link
Contributor

int19h commented Jan 22, 2024

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.

@lsmith77
Copy link

lsmith77 commented Jan 23, 2024

@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.

@bersbersbers
Copy link

I think the original issue has been fixed by emoji v2.10.1. For anyone working on this, here's another example:

bug.py:

import timeit
print(timeit.timeit("import colorcet", number=1))

Then run:

pip install colorcet debugpy
python bug.py
python -m debugpy --listen 5678 bug.py

For me, this prints

0.23384420000002137
0.01s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
15.49023370000009

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.

@cvzi
Copy link
Author

cvzi commented Mar 15, 2024

Yes it was "solved" in emoji module by compressing the dict literal into a single line, previously the dict was spread over ~87k lines

@cvzi
Copy link
Author

cvzi commented May 17, 2024

FYI for anyone considering this solution, unfortunately compressing the dict into a single line has created a new problem for us, it causes coverage report on Python 3.12 to use excessive amounts of memory (in our case more than 20 GB).

@bersbersbers
Copy link

causes coverage report on Python 3.12 to use excessive amounts of memory

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)

@Denelbe
Copy link

Denelbe commented Aug 29, 2024

I have a similar problem with module python-opcua.
The simple following script in vscode debugger runs in 2.7 seconds using Python 3.11.2 but 68 seconds with Python 3.12.5.

from opcua import Server 
server = Server()

OS Linux (Debian 12)
VsCode 1.92.2
Python Debugger 2024.10.0

@snmishra
Copy link

I've moved to pydevd. debugpy is unusable in Python 3.12, and I didn't want to go back to Python 3.11

@rchiodo
Copy link
Contributor

rchiodo commented Aug 29, 2024

Debugpy actually uses pydevd under the covers, but hasn't yet updated to pydevd's latest which has support for 3.12.

@laipz8200
Copy link

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:

  • Python Version: 3.12.5
  • Operating System: macOS 15.0
  • Chip: Apple M1 Pro

Thank you for your assistance!

Feel free to let me know if you would like any additional information.

@rchiodo
Copy link
Contributor

rchiodo commented Sep 3, 2024

I would like to understand the underlying cause of this delay and request guidance on how to resolve it.

Sorry there's nothing you can do. We need to finish moving to the new 3.12 sys.monitoring support.

@microsoft microsoft deleted a comment from derzinn Sep 4, 2024
@rteitge
Copy link

rteitge commented Sep 9, 2024

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.

@rchiodo
Copy link
Contributor

rchiodo commented Sep 9, 2024

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.

@rchiodo
Copy link
Contributor

rchiodo commented Sep 9, 2024

This item:
#1640

@rchiodo
Copy link
Contributor

rchiodo commented Sep 18, 2024

I'm pretty confident the pydev port will fix the performance issue.

Here's the difference for me between the two with the colorcet example:

With sys.monitoring

PS C:\Users\rchiodo\source\testing\test_pylance>  c:; cd 'c:\Users\rchiodo\source\testing\test_pylance'; & 'c:\Users\rchiodo\source\testing\test_pylance\.venv312\Scripts\python.exe' 'C:\Users\rchiodo\source\repos\debugpy\src\debugpy\adapter/../..\debugpy\launcher' '63855' '--' 'C:\Users\rchiodo\source\testing\test_pylance\test_slowdebugger.py' 
1.5255662000272423

With sys.trace

PS C:\Users\rchiodo\source\testing\test_pylance> ^C
PS C:\Users\rchiodo\source\testing\test_pylance> 
PS C:\Users\rchiodo\source\testing\test_pylance>  c:; cd 'c:\Users\rchiodo\source\testing\test_pylance'; & 'c:\Users\rchiodo\source\testing\test_pylance\.venv312\Scripts\python.exe' 'c:\Users\rchiodo\.vscode\extensions\ms-python.debugpy-2024.11.2024082901-win32-x64\bundled\libs\debugpy\adapter/../..\debugpy\launcher' '63993' '--' 'C:\Users\rchiodo\source\testing\test_pylance\test_slowdebugger.py' 
18.01146870001685

@rchiodo
Copy link
Contributor

rchiodo commented Sep 23, 2024

Reopening, hasn't shipped yet.

@rchiodo rchiodo reopened this Sep 23, 2024
@rchiodo
Copy link
Contributor

rchiodo commented Sep 24, 2024

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

@rchiodo rchiodo closed this as completed Sep 24, 2024
@bersbersbers
Copy link

bersbersbers commented Sep 25, 2024

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 debugpy in vscode-python-debugger:

pip install "debugpy>=1.8.6" --upgrade --target "%USERPROFILE%\.vscode\extensions\ms-python.debugpy-2024.10.0-win32-x64\bundled\libs"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants