This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ammar2, gwk, vstinner, xdegaye
Date 2017-02-01.22:37:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1485988651.5.0.148822192922.issue29400@psf.upfronthosting.co.za>
In-reply-to
Content
> I do not agree, Python debuggers are already really really slow. They should not have to process 'instruction' trace events as this would happen if George does "Remove the `else` to always trace with PyTrace_INSTRUCTION, rather than as an alternate to PyTrace_LINE as it does now".

Hum, there are two things:

* attached patch adds an else to the C maybe_call_line_trace(): I don't think that it's possible to notice the overhead in a debugger implemented in pure Python. If you are concerned by the change, we need a micro-benchmark.

* existing debuggers may have to be extended to support PyTrace_INSTRUCTION and so may be slowed down. Maybe I misunderstood what you wrote? For me, it's an opt-in feature: you must call sys.settraceinstr() instead of sys.settrace(), otherwise you don't get PyTrace_INSTRUCTION events. From the user point of view, I expect that the debugger starts at LINE level, but only switch to instruction level when I explicitly ask it to do so.
History
Date User Action Args
2017-02-01 22:37:31vstinnersetrecipients: + vstinner, xdegaye, gwk, ammar2
2017-02-01 22:37:31vstinnersetmessageid: <1485988651.5.0.148822192922.issue29400@psf.upfronthosting.co.za>
2017-02-01 22:37:31vstinnerlinkissue29400 messages
2017-02-01 22:37:31vstinnercreate