Package: dfly
Lightweight CPython DebuggerSynopsis•Installation•Usage•Compatibility•Documentation•Contribute•CreditsSynopsisDragonfly is a lightweight CPython debugger designed with speed in mind.
Contrary to more traditional debuggers, like pdb, Dragonfly does not rely
heavily on tracing, allowing the target application to run at full speed in most
cases. Occasionally, tracing might be required, so that the slowdown would be
similar to that of pdb in the worst case.InstallationThis package can be installed from PyPI withpipinstall--userdfly--upgradeUsageTo debug a Python script or application, simply prefix the command withdfly.
The built-inbreakpoint()is replaced with Dragonfly's own implementation, so
that you can set breakpoints in your code by simply addingbreakpoint()where
needed.Dragonfly is still in an early stage of development, so it is not yet feature
complete. However, it is already usable for the most common debugging tasks,
with some initial support for multi-threading.If you find this tool useful, please consider starring the repository and/or
becoming aSponsorto support the development.CompatibilityDragonfly is tested on Linux and macOS with Python 3.8-3.12.Why DragonflyThe typical CPython debugger relies heavily, or even exclusively on tracing in
their implementation. This technique is very powerful, but it has a few
shortcomings:high overhead - tracing is slow, and it can slow down the target application
by a factor of 10 or more.limited support for multithreading - supporting multithreading in a
tracing-based debugger is difficult, especially in older versions of Python.Some of these problems have been addressed inPEP 669. But whilst
the cost of monitoring has been lowered, some impact still remains. Besides,
PEP 669 is only available in Python 3.12 and later.Dragonfly poses itself as a lightweight alternative to the traditional, and the
PEP 669-based debuggers. At its core, Dragonfly uses bytecode transformation to
implement traps. These can be injected where breakpoints are requested, and
control is then passed to the prompt. When the targeted bytecode is already
being executed, Dragonfly turns on tracing to ensure that any breakpoints can
still be hit. In this case, the performance impact can be similar to that of
tracing-based debuggers. However, this should normally be a transient situation,
and the ammortised cost of debugging should be essentially negligible.To make this clearer, let's look at a simple example. Consider the following
code:deffibonacci(n):ifn<2:returnnreturnfibonacci(n-1)+fibonacci(n-2)fromtimeimportmonotonicastimestart=time()fibonacci(30)end=time()print(end-start)When we run this without any debuggers, the reported time is of the order of
0.1 seconds.$python3.12-mtests.fib0.11031840229406953If we run this with pdb, without any breakpoints, the reported time is of the
order of over 3 seconds:$python3.12-mpdb-mtests.fib> /tmp/fib.py(1)<module>()-> def fibonacci(n):(Pdb)r3.2781156906858087--Return--> /tmp/fib.py(12)<module>()->None-> print(end - start)(Pdb)However, if we run it through Dragonfly, again without any breakpoints set, the
reported time is essentially the same as without any debugger:$dfly-rpython-mfib0.11001458810642362Bytecode debuggingDragonfly can also be used to debug CPython at the bytecode level. When settingtrace-opcodeswithset trace-opcodes 1, every stepping operation will be
performed at the bytecode level. Thedisassemblecommand can be used to
display the bytecode currently running, along with the values in the stack for
the current frame.ContributeIf you want to help with the development, then have a look at the open issues
and have a look at thecontributing guidelinesbefore you
open a pull request.You can also contribute to the development by eitherbecoming a
Patronon Patreon, bybuying me a
coffeeon BMC or by chipping in a few
pennies onPayPal.Me.CreditsArtwork byAntea a.k.a. Aisling.