I'm trying to better understand how to interpret chrome flame charts.
In the below chart _changeHandler
is shown as four distinct blocks.
However I know for fact that it's only being called once.
I saw a similar question here, which claims this might be a bug, but that was four years ago:
What are this gap mean in Chrome devtools profile flame chart
Question:
In which case would chrome perf tools show gaps in the flame chart for the same function call ?
The real problem is that it really invalidates the entire graph. The bottom of the graph fragments but the top parts are the same function. I can't figure out how to make sense of that at all.
When using cpu throttling, the problem becomes exponentially worse.
Look at the second picture, it's the same operation as the first graph, but with cpu throttling set to 5x slowdown.
The fragmented bar under "Function Call" is a single function call, for some reason it's fragmented in hundreds of sections.
The x-axis of a flame graph measures the duration of each span in the request, so wider spans took more time to complete. The y-axis measures the depth of the call stack (i.e., the number of service calls). Clicking a span on the flame graph typically brings up duration and error data for that service call.
FlameGraphs, invented by Brendan Gregg, help visually summarize on-CPU call stacks. Below is an image of a FlameGraph generated from a 10-second run of the evict-btree-stress-multi wtperf job: To see it in action, download the non-redacted interactive version here and open it in your web browser.
Neelakanth and Roch's visualizations used completely random colors to differentiate frames. I thought it looked nicer to narrow the color palette, and picked just warm colors initially as it explained why the CPUs were "hot" (busy). Since it resembled flames, it quickly became known as flame graphs.
Thing is, we get the JS function data by sampling (unlike native events that we get by instrumenting start/stop). So internally it's just 4 samples that landed into the said function. We don't know if it was executed once or 4 times or 100 times, but we do our best to glue them so as it appeared as one call as long as the samples are adjacent.
But sometimes this logic mysteriously fails. Most of the time, this is because of some problems while sampling the JS stack (if some inlined or native function is on top, we sometimes fail to unwind the stack properly).
Source: Chat with a DevTools engineer
If you want to privately submit a url / steps to reproduce, the team can check it out. They thought they fixed this category of bugs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With