[issue28924] Inline PyEval_EvalFrameEx() in callers

STINNER Victor added the comment: > At least define EvalFrameEx in a header as an inline func, rather than > copying the body. Hum, it would break the stable ABI, no? -- ___ Python tracker ___

[issue28924] Inline PyEval_EvalFrameEx() in callers

STINNER Victor added the comment: Well, since the impact on performance is likely non-existent, whereas drawbacks are real, I close the issue. Thanks for your feedback ;-) -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue28924] Inline PyEval_EvalFrameEx() in callers

Steve Dower added the comment: At least define EvalFrameEx in a header as an inline func, rather than copying the body. VS expected to walk the native stack and locate the f parameter in EvalFrameEx. Since the function gets inlined, it couldn't find the frame. I use the JIT hook to insert my

[issue28924] Inline PyEval_EvalFrameEx() in callers

STINNER Victor added the comment: Serhiy: "Since almost all calls of PyEval_EvalFrameEx() are in the same file as its definition, I suppose the compiler can inline it even without PGO." Let me check. My patch changes gen_send_ex() of genobject.c and _PyEval_EvalCodeWithName() of ceval.c. "gcc

[issue28924] Inline PyEval_EvalFrameEx() in callers

Serhiy Storchaka added the comment: Ah, now I see. I was confused by the fact that eval_frame is set only to _PyEval_EvalFrameDefault. But how large the gain of inlining PyEval_EvalFrameEx()? Is it worth cluttering the code? Since almost all calls of PyEval_EvalFrameEx() are in the same file

[issue28924] Inline PyEval_EvalFrameEx() in callers

STINNER Victor added the comment: Serhiy: "May be just replace inlined call with _PyEval_EvalFrameDefault?" Do you mean replacing PyEval_EvalFrameEx() with _PyEval_EvalFrameDefault()? It would defeat the purpose of the PEP 523, no? -- ___ Python tra

[issue28924] Inline PyEval_EvalFrameEx() in callers

Serhiy Storchaka added the comment: May be just replace inlined call with _PyEval_EvalFrameDefault? -- ___ Python tracker ___ ___ Pyth

[issue28924] Inline PyEval_EvalFrameEx() in callers

STINNER Victor added the comment: > It may break other debuggers like Python Tools for Visual Studio, though > (+steve.dower for that). Do you mean debuggers expecting that bytecode is run in PyEval_EvalFrameEx() rather than PyEval_EvalFrameDefault()? Can't we fix these debuggers? > IMHO, in

[issue28924] Inline PyEval_EvalFrameEx() in callers

Steve Dower added the comment: MSVC automatically inlines it on Windows (and yes, it broke some of our debugging support in Visual Studio, but we can fix it by setting the eval func). IMHO, inlining is best left to profiling optimizers. If you notice a regression, add a test case that drives i

[issue28924] Inline PyEval_EvalFrameEx() in callers

Brett Cannon added the comment: Inlining wouldn't break Pyjion since all of its smarts would be in the trampoline function in PyInterpreterState. It may break other debuggers like Python Tools for Visual Studio, though (+steve.dower for that). But is the overhead honestly that high to warrant

[issue28924] Inline PyEval_EvalFrameEx() in callers

New submission from STINNER Victor: Inline PyEval_EvalFrameEx() in callers. The PEP 523 modified PyEval_EvalFrameEx(): it's now an indirection to interp->eval_frame(). Inline the call in performance critical code. Leave PyEval_EvalFrame() unchanged, this function is only kept for backward comp