On Mon, May 16, 2016 at 1:19 PM, Dino Viehland
It also opens up the possibility of debugging where the frame evaluation function only performs special debugging work when it detects it is about to execute a specific code object. In that instance the bytecode could be theoretically rewritten in-place to inject a breakpoint function call at the proper point for help in debugging while not having to do a heavy-handed approach as required by sys.settrace().
To add to the debugging story: there are many debugging/profiling tools that look at C symbol names. When you have a mixed C/Python codebase, too often a problem straddles both sides -- the Python tools don't tell you anything about the C end, and the C tools just tell you that everything happened in PyEval_EvalFrameEx. Instead of plugging in a JIT-compiled version of a code object, one can plug in a shim, so that each code object has a function with a unique symbol name that only calls PyEval_EvalFrameDefault. This way, you get symbol names for all Python functions. So while it still says that 90% CPU is used by PyEval_EvalFrameEx, it also then that breaks down into 12% being used by PY_SYMBOL__jsonĀ·load or similar, which is a symbol corresponding to the code object for the Python function json.load. I'm +1 for something that makes this possible, although for the specific API proposal here, no real opinions. -- Devin