Add a low-overhead profiling mode which only collects markers and no sample-based information
Categories
(Core :: Gecko Profiler, enhancement, P3)
Tracking
()
People
(Reporter: mstange, Assigned: mozbugz)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
The profiler's stack sampling provides very useful information but also has a lot of overhead. For example, we cannot run the profiler during regular Talos runs because it would disturb the measurement too much. We also cannot do any power usage profiling with stack sampling enabled, because sampling uses too much power.
In many cases, the information from markers is already really helpful on its own. It would be nice to have a mode in the profiler which only collects markers.
This would let us correlate markers and power numbers, and maybe even let us collect profiles in Talos tests by default.
At the moment, you can get an approximation of this by setting the interval to a really high value (very low frequency). But this is really just a workaround. The profiler only collects markers into the buffer whenever it gets a sample, so it's possible to miss markers that way.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Part of this work should also be reviewing and combining the many JS sampling related options; based on use cases and overhead.
Comment 2•5 years ago
|
||
I'd revise that to "doesn't collect sampled stack traces". which allows for possible sampling-on-event, and for collection of counters (such as memory counters), which are low-overhead (timer event and (small) number of bufferentry insertions timer firing). We should consider if it's worth turning that off as well (avoid wakeups that affect power, etc).
As part of low-overhead, we should have a second bug on lowering the overhead of markers
Reporter | ||
Comment 3•5 years ago
|
||
Right, I was thinking about the power overhead of the wakeups. But yes, we can make all of those levers independent.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
If all sampling-related features ("Native Stacks", "JavaScript", and "Native
Leaf Stack") are OFF, the sampler loop will not record any stack samples, not
even from labels, which should reduce the power consumption significantly.
This means that the sampling rate could be slowed down (up to 5s interval), to
help reduce the power consumption incurred by wake-ups for sampling.
Markers are not affected by this, and will all be recorded as expected.
However counters (e.g., memory allocations) are still tied to sampling, so their
sampling resolution will be reduced to whatever sampling rate is chosen.
Some existing tests relied on stack sampling happening, so they now enable at
least "leaf". Bug 1579333 may revisit these tests for a better solution (if
possible).
Assignee | ||
Updated•5 years ago
|
Comment 6•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Description
•