Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Ain’t no game using 20ms frames!

A frame every 20ms equates to 50 frames per second. Doesn't seem too unreasonable for a modern game.

60 frames per second would be one frame every ~16 ms.



Correct. Which means that every 20ms pixel slices two or three frames. Which is a really really bad way to profile!


I could just regenerate these heat maps with 60 rows instead of 50. I'm limited by the sampling rate that was captured in the profile data file. To provide even more resolution (so you had many samples within a game frame) I'd need to re-profile the target with a higher frequency.

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


> Correct. Which means that every 20ms pixel slices two or three frames. Which is a really really bad way to profile!

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.


The issue isn’t that 20ms is an unreasonable slice size. The issue is you can’t perform an arbitrary slice.

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?


Ah yes. Ok.

Yes, that makes perfect sense. Thanks.


It sounds like your problem might be not with the visualization itself, but with the underlying idea of a sampling profiler as opposed to tracing every single call from every single frame.


No. Sampling profilers are great. Most powerful is of course a mix of sampling and instrumentation. But nothing beats the feeling of a sampling profiler fixing big issues in under 5 minutes.

Flamegraphs are a nice tool to have in the bag I suppose. But they’re more tertiary than primary or even secondary to me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: