Disable automatic update of frame locals during tracing

[fabioz]

BPO	42197
Nosy	@ncoghlan, @vstinner, @fabioz, @nedbat, @markshannon
PRs	bpo-42197: Disable automatic update of frame locals during tracing #23028 bpo-42197: Don't create f_locals dictionary unless we actually need it. #32055

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-10-29.14:16:41.031>
labels = ['interpreter-core', '3.11', 'performance']
title = 'Disable automatic update of frame locals during tracing'
updated_at = <Date 2022-03-28.06:57:42.353>
user = 'https://github.com/fabioz'

bugs.python.org fields:

activity = <Date 2022-03-28.06:57:42.353>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2020-10-29.14:16:41.031>
creator = 'fabioz'
dependencies = []
files = []
hgrepos = []
issue_num = 42197
keywords = ['patch']
message_count = 19.0
messages = ['379874', '385320', '385323', '385329', '385336', '396563', '396572', '396574', '396576', '411108', '411111', '411112', '411114', '411145', '411177', '411210', '415801', '415998', '416145']
nosy_count = 6.0
nosy_names = ['ncoghlan', 'vstinner', 'fabioz', 'nedbat', 'Mark.Shannon', 'python-dev']
pr_nums = ['23028', '32055']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue42197'
versions = ['Python 3.11']

[fabioz]

Right now, when a debugger is active, the number of local variables can affect the tracing speed quite a lot.

For instance, having tracing setup in a program such as the one below takes 4.64 seconds to run, yet, changing all the variables to have the same name -- i.e.: change all assignments to a = 1 (such that there's only a single variable in the namespace), it takes 1.47 seconds (in my machine)... the higher the number of variables, the slower the tracing becomes.

import time
t = time.time()

def call():
    a = 1
    b = 1
    c = 1
    d = 1
    e = 1
    f = 1

def noop(frame, event, arg):
    return noop

import sys
sys.settrace(noop)

for i in range(1_000_000):
    call()

print('%.2fs' % (time.time() - t,))

This happens because PyFrame_FastToLocalsWithError and PyFrame_LocalsToFast are called inside the call_trampoline (https://github.com/python/cpython/blob/master/Python/sysmodule.c#L946).

So, I'd like to simply remove those calls.

Debuggers can call PyFrame_LocalsToFast when needed -- otherwise mutating non-current frames doesn't work anyways. As a note, pydevd already has such a call: https://github.com/fabioz/PyDev.Debugger/blob/0d4d210f01a1c0a8647178b2e665b53ab113509d/_pydevd_bundle/pydevd_save_locals.py#L57 and PyPy also has a counterpart.

As for PyFrame_FastToLocalsWithError, I don't really see any reason to call it at all.

i.e.: something as the code below prints the a variable from the main() frame regardless of that and I checked all pydevd tests and nothing seems to be affected (it seems that accessing f_locals already does this:

cpython/Objects/frameobject.c

Line 35 in cb9879b

frame_getlocals(PyFrameObject *f, void *closure)

, so, I don't see much reason to call it at all).

def call():
    import sys
    frame = sys._getframe()
    print(frame.f_back.f_locals)
   
def main():
    a = 1
    call()
   
if __name__ == '__main__':
    main()

So, the idea is removing those lines (I expect that I'll be able to provide a pull request for this).

[vstinner]

Fabio created a thread on python-dev:
https://mail.python.org/archives/list/python-dev@python.org/thread/62WK3THUDNWZCDOMXXDZFG3O4LIOIP4W/

In 2017, Nick Coghlan wrote the PEP-558 "Defined semantics for locals()".

[vstinner]

Mark: do you think that it's an acceptable trade-off to ask debuggers and profilers to call explicitly PyFrame_FastToLocalsWithError() and PyFrame_LocalsToFast(), to optimize the common case, when locals are not needed?

[markshannon]

I don't think so.
Tracing is already somewhat fragile, see https://bugs.python.org/issue30744.
Making it more complex is likely to add more bugs.

PEP-558 should help, as f_locals becomes a proxy.
There are some minor issues with PEP-558 (I'm not convinced that it is completely robust), but it should fix this issue.

Ultimately, what we need is a decent debugger API, something along the lines of the JVMTI.

[fabioz]

I agree that it can be made better, but I think most of the issues right now comes from CPython trying to automatically do something that's not bound to work (calling PyFrame_FastToLocals/PyFrame_LocalsToFast under the hood during the tracing call).

https://bugs.python.org/issue30744 is a great example of why that can never work properly (debuggers need to manage that much more carefully, just doing it on all calls is really bound to not work).

So, the current implementation besides being broken also makes things pretty slow.

I agree that PEP-558 may fix things here (but it's much more work).

As a disclaimer, pydevd actually uses a different tracer which doesn't do those calls and when possible uses the frame eval to modify the bytecode directly to minimize the overhead, so, in practice the current support given by CPython for debugger is pretty reasonable for doing a fast debugger (but there are a few caveats that it must work around -- such as the auto PyFrame_FastToLocals/PyFrame_LocalsToFast calls).

[ncoghlan]

I've updated PEP-558 with a reference back to this ticket as additional motivation (the update also addresses several of the fragility concerns that Mark raised): python/peps#1787

There's still work to be done to bring the reference implementation into line with the updated proposal, but I'm making it an explicit goal to get the proposal submitted for pronouncement in time for inclusion in 3.11.