Aaron Puchert wrote:
Actually, DWARF based profiling isn't very good, which is why so few people do it. It's slow, it's memory intensive, thus the sampling capability is much poorer. That's an oversimplification. It's certainly slower and generates larger
Am 18.11.24 um 13:02 schrieb Neal Gompa: profiles, but it's also much more powerful. You can see inlined functions and get an association to source code lines in the annotation. Sometimes knowing the function names is enough, but especially in a larger code base or if you're not so familiar with the code that you can match assembly with source lines manually, this can be enormously helpful. For my part, I prefer DWARF profiling when I have the debug info around.
You are mixing up two separate things: stack trace capture (a.k.a. unwinding) and stack trace symbolization. What you talk about about DWARF and inline functions, that's about stack trace symbolization, which involves translating a collection of raw memory addresses (representing function call frames) to something human-readable. No matter how you got raw stack trace data (addresses, just numbers), with the use of frame pointers or not, you'd need to symbolize it to make sense. At that point either basic ELF symbol-based symbolization can be done (cheap, pretty fast, but missing inline functions and source code location information) or, if DWARF is available, it's possible to get inline function calls and/or source code information. But again, this is besides the frame pointer or not discussiong. Frame pointers help to get (mostly) reliable stack trace *capture*/unwinding cheaply and efficiently. The alternative to that would be ORC (in kernel only), SFrame (when it's properly supported), or DWARF's .eh_frame-based stack unwinding tables. The latter is actually doesn't land itself well to system-wide profiling, and involved compromises in memory usage, CPU usage, and just plain reliability (no one will guarantee you that you captured all of the stack, for example). It's too much to describe all the nuances of frame pointer vs DWARF-based (.eh_frame-based) stack unwinding. The latter just doesn't work well, frame pointer is currently the only reliably and efficient way to do this. Until something like SFrame gets adopted and supported widely.