Discussion of ways to actually improve the speed in the PTVS debugger, rather than workarounds. By 'PTVS debugger', I am referring to whatever PTVS component manages the execution of the Python script when launched under the VS IDE (via F5).
I know this issue has been raised before, but I thought a new issue would bring better attention.
The gist of explanation about the debugging slowness, as I understand it
, is that the debugger runs the Python interpreter in a trace mode. I don't know the details, but it seems that the debugger is invoked whenever the current line changes.
The reason this is done
is so that when an exception is thrown, the debugger can determine, or at least guess, whether there is a handler for the exception. If the exception is not checked in the Exceptions dialog as 'thrown' but is checked as 'user-unhandled',
this will determine whether or not to break. BTW, I have posted a separate issue to clarify what 'user-unhandled' means exactly.
I would like to suggest
that this can be determined from code analysis rather than from tracing. I believe the object is to know what
try ... except
blocks are active on the execution stack. Can't you examine the source code as indicated in the exception traceback and find the
block(s) that enclose each point in the traceback?
Or better yet
, could you examine the byte code; this would cover cases where there is no source code available. This would also solve the issue of not knowing about exception handlers where there is no source code.
Previous discussion about the slowness issue has to do with reducing the time spent handling trace callbacks from the interpreter. However, the sheer number of such callbacks makes the debugger much too slow. That is why I have asked if the trace is really
is to eliminate the trace mode in the case that there are no User-unhandled exceptions checked at all. I would think this would be easy to implement. If you do implement this feature, then you should update the documentation
to point out (with emphasis) that unchecking all exceptions will result in considerably faster debugging.
Finally, how can I help
implement this? At least, can you point me to where in the PTVS source the logic for handling exception breaks is located, so that I could see how complicated a task it would be?
... The trace seems to go so far as to call back for continuation lines in the source code. The result is that a statement that extends over two or more lines takes longer in debugging than if the statement is put into a single line. Even
statement 1; \
runs slower than
statement 1; statement 2
with the result that in order to speed up the debugging of very frequently executed code, I have to make it less readable!