Ptvs: Very slow loading after "Enable native code debugging"

Created on 18 Dec 2018  路  10Comments  路  Source: microsoft/PTVS

I have following this post and get mix mode debug working.
VS version : Community 2017
Python version : 3.71
Running on Window-10

The loading time of the project become very slow (> 30 secs) after the "Enable native code debugging" feature is enabled.
I believe due to matplotlib & socket is imported in Python project.
As I use a sample project to start, it cut down to (10 secs), still longer than normal Python Debug start (1 sec).

As my most interest is debugging the C code, any method to improve loading time ?

Debugger Native Modules enhancement Performance

Most helpful comment

This usually happens on importing of very large packages, mostly because the debugger is tracking the creation of code objects, and there are a lot of them (one per function).

The workaround is, indeed, to attach after imports are done.

A long-term fix would be to implement Just My Code in the mixed-mode debugger, so that imported modules aren't traced at all, and all internal breakpoints are disabled inside them.

All 10 comments

I don't know of any way of speeding up the mixed mode debugger (yes it is slow compared to the python debugger). Maybe @int19h as ideas?

Maybe start without debugging, then debug->attach would actually save you time, despite the manual steps?

This usually happens on importing of very large packages, mostly because the debugger is tracking the creation of code objects, and there are a lot of them (one per function).

The workaround is, indeed, to attach after imports are done.

A long-term fix would be to implement Just My Code in the mixed-mode debugger, so that imported modules aren't traced at all, and all internal breakpoints are disabled inside them.

The suggestion to "attach after imports are done" doesn't seem to help. As soon as attach, I experience the same loading delay. FYI, we have a large python/C++ codebase and loading can take up to 3 minutes on a hot rod machine when "Enable native code debugging" is enabled. And for 99.9% of the modules loaded I don't need source level debugging. I'm curious why the "Symbols: Load only specified modules" radio button can't be used to limit the Python modules which can be used for source debugging.

Python modules don't actually have symbols, it's just a VS artifact. Since the actual slowdown comes from tracing code unnecessarily as it runs, JMC is the proper knob for such a feature. We just don't have anything like that implemented yet.

Can you tell a little bit more about what the experience looks like when you attach post-import? Is there anything else printed in debugger output window in addition to all the "Module loaded" notifications? e.g. exceptions?

No exceptions were seen. The load process pauses momentarily for like a second or two on a couple of modules, but generally the load listing progresses pretty smoothly.

Here are the load timings for VS2017 Version 15.9.6:

Legacy Debugger:
Normal, Python only debugging: 3 seconds
Python / C++ debugging, Debug.StartDebugging:  4 minutes
Python only, then Debug.AttachToProcess: 100 seconds

NOT Legacy Debugger:
Normal, Python only debugging: 3 seconds
Python / C++ debugging, Debug.StartDebugging:  6 minutes
Python only, then Debug.AttachToProcess: 130 seconds

I've attached the output from Debug.AttachToProcess and Debug.StartDebugging.

AttachToProccess.txt
DebugRun.txt

Oh, and of course the yellow banner at the top of the VS2017 screen is proclaiming:
"Debugger performance may be improved by loading fewer symbols"
which gives a false sense of hope.

Sorry for going dark on this for so long. And thank you for the logs and the numbers! Yeah, it sure looks like it's a general perf issue, because everything gets traced. We really do need JMC for mixed-mode.

@huguesv, you might want to make this one a tracking bug for it. Or create a new one - I think we had some perf bugs on MMD, but they were probably closed a long time ago.

Thanks @int19h we did have another one, but we'll keep this one since it has the discussion.

Any update on a fix for this? Just My Code for Mixed-Mode Debugging would be a lifesaver for me!

I'm dying trying to work around this - I end up having to identify one of three python processes with changing PID's, on top of the manual attaching, making the mixed-mode debugging process particularly difficult/annoying. Any update on Just My Code? If not, how does one name a VS debugging process for identification and automatic attaching?

Was this page helpful?
0 / 5 - 0 ratings