Repository navigation
Show calls to native code and GC in profiles #140643
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancementinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory3.15bugs and security fixesbugs and security fixes
on Oct 26, 2025 I tried an experiment a while ago to put minimal "interpreter frame"s on the C stack (just a few fields) for builtin functions and link them through the interpreter frame stack. The cost was small (about 3 writes and a read on entry and a read and write on exit).
Benchmarking showed no significant slowdown. Unfortunately, I seem to have neither that code nor results.Here's a branch (probably from a different experiment) that shows some of the refactoring of the frame necessary.
https://github.com/faster-cpython/cpython/tree/push-extension-frameI suspect this would be a bit slower than your approach, but a lot easier for existing tools to work with.
Reacted by Pablo Galindo Salgado and Mikhail EfimovI think @markshannon idea is very interesting and is worth trying. Maybe we could put a pointer to the Cfunction object somewhere in the thread state instead? 🤔
I'm not sure how useful that would be though, since we'd only have a pointer to the first native function entered, not everything after that. Unless you're saying that we push this minimal frame on every PyCFunction call, not just ones that leave the interpreter?
Either way, I think I'll just start with dummy
<native>frames in the profiler output and then we can iterate on improving that as a follow up, weighing the cost of the slowdown. Definitely seems interesting, though.- added a commit that references this issue
on Nov 17, 2025 Let's use another issue for the improved native frame tracking
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
Feature or enhancement
Without too much effort (and negligible overhead in the profiler), we can add some useful additional functionality to the new sampling profiler:
<native>frame in the collected stack between the Python frames.<GC>dummy frames. Any Python code running in finalizers, GC callbacks, or weakref callbacks will be below these in the stack.@pablogsal and I discussed this at the sprint, and he seemed excited for it. I implemented most of it there, and will open a PR shortly once I've cleaned things up a bit and added docs.
Linked PRs
<native>and<GC>frames to the sampling profiler #141108