Correct. Which means that every 20ms pixel slices two or three frames. Which is a really really bad way to profile!
When Martin, my colleague at Netflix at the time, built a d3 version of FlameScope, he put a row selector in the UI: https://github.com/Netflix/flamescope
If 20 ms is a reasonable frame time for a modern game, why is it an unreasonable thing to profile?
I understand other, shorter, frame times may be interesting to profile too. My point is that if you want to understand a reasonable or realistic workload, then it should also be reasonable to profile that workload.
Imagine a game that runs at 50Hz/20ms frame. Unusual but let’s go with it because the exact value doesn’t matter. Ideally this update takes AT MOST 20ms. Otherwise we miss a frame. Which means most frames actually take maybe 15ms. And some may take only 5ms. If you drew this on a timeline there would be obvious sleeps waiting for the next frame to kick off.
If you take an arbitrary sequence of 20ms slices you’re not going to capture individual frames. You’re going to straddle frames. Which is really bad and means each pixel is measuring a totally different body of work.
Does that make sense?
Yes, that makes perfect sense. Thanks.
Flamegraphs are a nice tool to have in the bag I suppose. But they’re more tertiary than primary or even secondary to me.