Where Does CPython Spend Its Time?

[ericsnowcurrently]

(This is an offshoot of #410.)

It would be helpful to have a good idea of where CPython spends its time, both generally and on a per-workload basis. First it's worth identifying high-level categories and then it's worth finding out how much time we spend in each (and even what is actually executing in each case, including the call chains).

---

Here's a first stab at the high-level categories:

• main (incl. the top-level PyRun_AnyFileFlags(), etc. call)
• runtime lifecycle (init/fini; runtime + interpreter)
• extension code (stdlib/3rd-party) (init; module functions vs. classes/methods)
• C-API functions (for which the implementation often includes one or more internal functions)
• eval loop (#144 breaks this one up at a more granular level)
• builtin types
• builtin functions
• ...
• elsewhere in the runtime code

(Another avenue to possibly investigate is the incidence rate of the transition between any two of those categories.)

Once we have categories, we'd want to assign all exported functions to one category, and all internal functions to one (or more) exported function. That way we can map function-keyed data onto categories.

---

So...how do we get there? Profiling! (That can be tracing or sampling or both.)

Here are some profiling results that may help us:

• time spent in a function
• instructions (cycles) in a function
• flame graphs
• call traces (i.e. flatten out the effective sequential path of calls into some kind of sequence diagram)
• ...

We can probably also get close-enough results for those with some form of static analysis.

---

Also see #143, #127, #144, #151, and #136.

[bgruening]

Maybe https://github.com/benfred/py-spy can help here?

[ericsnowcurrently]

That's a cool tool! Here we're talking about profiling the CPython implementation rather than any Python code it is running. There's a bit more discussion about profiling the runtime in #143.