I have tried debugging Python 3 with Wing IDE (v.4.1.3) and Komodo IDE (v.7.0.0). As, expected the debugger adds a lot of run-time overhead. But what surprised me is how different the debuggers can be between each other.
Here are the run-times for the same program. No breakpoints or anything else, just a regular run without any actual debugging:
- executed by python interpreter: 26 sec
- executed by debugger #1: 137 sec
- executed by debugger #2: 1143 sec
I refer to the debuggers as anonymous #1 and #2 lest this becomes an unintentional (and possibly misguided) advertising for one of them.
Is one of the debuggers really 8 times “faster”?
Or is there some design trade-off, where a faster debugger gives up some features, or precision, or robustness, or whatever, in return for greater speed? If so, I’d love to know those details, whether for Wing/Komodo specifically, or Python debuggers in general.
Doing an optimized Python debugger is as any other software: things can be really different performance-wise (I’m the PyDev author and I’ve done the PyDev debugger, so, I can comment on it, but not on the others, so, I’ll just explain a bit on optimizing a Python debugger — as I’ve spent a lot of time optimizing the PyDev debugger — I won’t really talk about other implementations as I don’t know how they were done — except for pdb, but pdb is not really a fast debugger implementation after it hits a breakpoint and you’re stepping through it, although it does work well by running things untraced until you actually execute the code that’ll start tracing your code).
Particularly, any ‘naive’ debugger can make your program much slower just by enabling the Python trace in each frame and checking if there’s a breakpoint match for each line executed (this is roughly how pdb works: whenever you enter a context it’ll trace it and for each line called it’ll check if a breakpoint matches it, so, I believe any implementation that expects to be fast can’t really rely on it).
I know the PyDev debugger has several optimizations… the major one is the following: when the debugger enters a new frame (i.e.: function) it will check if there’s any ‘potential’ breakpoint that may be hit there and if there’s not, it won’t even trace that function (on the other hand, when a breakpoint is added later on after the program is executing, it’ll have to go and reevaluate all previous assumptions, as any current frame could end up skipping a breakpoint). And if it determines that some frame should be traced, it’ll create a new instance for that frame which will be responsible for caching all that’s related to that frame (this was only really possible from Python 2.5, so, when working on Python 2.4 and earlier, unless the threadframe extension is installed, the debugger will try to emulate that, which will make it considerably slower on Python 2.4).
Also, the PyDev debugger currently takes advantage of Cython, even though this is only restricted to CPython… Jython, IronPython and PyPy don’t take advantage of it), so, many optimizations are still done considering pure Python mode (thankfully Cython is close enough to Python so that few changes are needed in order to make it work faster on CPython with Cython).
Some related posts regarding PyDev debugger optimization evolution:
http://pydev.blogspot.co.id/2017/03/pydev-560-released-faster-debugger.html
http://pydev.blogspot.co.id/2016/01/pydev-451-debug-faster.html
http://pydev.blogspot.com/2008/02/pydev-debugger-and-psyco-speedups.html
http://pydev.blogspot.com/2005/10/high-speed-debugger.html
Anyways, running with the debugger in place will always add some overhead (even when heavily optimized such as the PyDev debugger), so, PyDev also provides the same approach that may be used in pdb: add a breakpoint in code and it’ll only start tracing at that point (which is the remote debugger feature of PyDev): http://pydev.org/manual_adv_remote_debugger.html
And depending on the features you want the debugger to support, it can also be slower (e.g.: when you enable the break for caught exceptions in PyDev, the program will execute slower because it’ll need to trace more things in order to properly break).