Message 305586 - Python tracker

➜

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	ncoghlan
Recipients	Mark.Shannon, arigo, belopolsky, benjamin.peterson, ncoghlan, njs, xdegaye, xgdomingo, yselivanov
Date	2017-11-05.05:55:40
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<[email protected]>
In-reply-to

Content
Starting to make some progress on an implementation, and it occurs to me that if this approach does work out, it should make Python level trace functions much faster. Right now, the call to the Python function in call_trampoline is bracketed by PyFrame_FastToLocals() and PyFrame_LocalsToFast(), even if the trace function never accesses frame.f_locals. By contrast, with the proposed design, PyFrame_LocalsToFast() never gets called anywhere (I've actually replaced the entire body with a PyErr_SetString call), and PyFrame_FastTo_Locals will only be called in the frame.f_locals descriptor implementation.

Starting to make some progress on an implementation, and it occurs to me that if this approach does work out, it should make Python level trace functions *much* faster.

Right now, the call to the Python function in call_trampoline is bracketed by PyFrame_FastToLocals() and PyFrame_LocalsToFast(), even if the trace function never accesses frame.f_locals.

By contrast, with the proposed design, PyFrame_LocalsToFast() never gets called anywhere (I've actually replaced the entire body with a PyErr_SetString call), and PyFrame_FastTo_Locals will only be called in the frame.f_locals descriptor implementation.

History
Date	User	Action	Args
2017-11-05 05:55:41	ncoghlan	set	recipients: + ncoghlan, arigo, belopolsky, benjamin.peterson, njs, xdegaye, Mark.Shannon, yselivanov, xgdomingo
2017-11-05 05:55:41	ncoghlan	set	messageid: <[email protected]>
2017-11-05 05:55:41	ncoghlan	link	issue30744 messages
2017-11-05 05:55:40	ncoghlan	create