Flame Graph segment width seems to be weighted by sample count rather than time

This comes up particularly with off-cpu profiling, where one stack sample (when a thread blocks on IO or mutex) might represent a large wall-clock duration.

Compare this screenshot, where a segment has 237 samples and takes 49ms:

With this screenshot, where a segment has 75 samples and takes 9600ms:

I’d expect the 9600ms section to be about 9600/49=195 times larger, but instead the 49ms span is wider.

Here’s an offcpu profile to reproduce with: 2021-09-17-200119506-obfuscated.firefox.json.gz

This was generated using Android simpleperf using off-cpu tracing @4000Hz for 30s:

$ simpleperf/app_profiler.py -p com.google.android.apps.maps -r "-f 4000 -g -e cpu-clock --trace-offcpu --duration 30" --activity com.google.android.maps.MapsActivity --skip_collect_binaries

Then converted to firefox profiler format.

[julienw]

Yes, we’re still interested! Thanks a lot for looking at this 😃

[ryoqun]

fyi, i created a very rough pr to fix this. at least, it should be working #4320

is anyone still interested? if so, i may prioritize finishing up the pr.