debugging: slides: properly introduce flamegraphs and hotspot #269
Conversation
Flamegraphs, while being a very valuable tool to get a graphical view of some profiling data, are only lightly covered, very early, and somehow in the middle of other concepts. Rework flamegraphs introduction to really introduce how to generate and read them: - move the flamegraph content in the system-wide profiling part, after having introduced the general perf commands, needed to generate flamegraph data - explain how to fetch the scripts and how to use them - add instructions about how to read a flamegraph, and a custom CPU flamegraph to illustrate it - add hotspot as an alternative/extension The only downside is that, now that flamegraphs are introduced later, we reach the heaptrack part without having introduced flamegraphs, but it may be fine to just announce that "we will cover flamegraphs more in details later" Fix #267 Signed-off-by: Alexis Lothoré <[email protected]>
| \end{block} | ||
| \begin{itemize} | ||
| \item \code{stackcollapse-perf.pl} is part of the | ||
| \href{https://github.com/brendangregg/FlameGraph}{Flamegraph |
There was a problem hiding this comment.
I don't think this bullet is needed, it's implied by the git clone line above.
There was a problem hiding this comment.
Yeah, agree. When I added this line, the git clone instruction was not here yet, so it kind of anticipated some questions, but now it does bring much. I'll remove it
| \item Format the data: | ||
| \begin{block}{} | ||
| \begin{minted}[fontsize=\small]{console} | ||
| perf script|./fl/stackcollapse-perf.pl > out.perf-folded |
There was a problem hiding this comment.
Minor nit: I'd add a whitespace before and after the | for readability.
| \center | ||
| \includegraphics[width=1.0\textwidth]{slides/debugging-system-wide-profiling/flamegraph.png}\\ | ||
| \begin{itemize} | ||
| \item The plates width represents how often a function has been |
There was a problem hiding this comment.
"how often it has been sampled" or "for how long it has been active on the stack?" -- in other words, it represents number of events or execution time?
There was a problem hiding this comment.
Technically, it really is the first one. But then, assuming the sampling frequency is high enough, it gives an idea/estimate of the second one, relatively to anything else running on the platform.
One point I could add to clarify this is that when a plate is inside a "stack of plates", it has not specifically been sampled by perf/the kernel, it was just in the call stack of another function (let's call it foo) which as been actually sampled. And foo is then at the top of the "plate stack". Does it make more sense this way ?
There was a problem hiding this comment.
Modifications done and pushed in dedicated commits for review, those will be squashed before integration
Signed-off-by: Alexis Lothoré <[email protected]>
Signed-off-by: Alexis Lothoré <[email protected]>
Signed-off-by: Alexis Lothoré <[email protected]>
Flamegraphs, while being a very valuable tool to get a graphical view of some profiling data, are only lightly covered, very early, and somehow in the middle of other concepts.
Rework flamegraphs introduction to really introduce how to generate and read them:
The only downside is that, now that flamegraphs are introduced later, we reach the heaptrack part without having introduced flamegraphs, but it may be fine to just announce that "we will cover flamegraphs more in details later"
Fix #267
Preview of the new slides