Closed Bug 1549482 Opened 2 years ago Closed 1 year ago

Add a low-overhead profiling mode which only collects markers and no sample-based information


(Core :: Gecko Profiler, enhancement, P3)




Tracking Status
firefox68 --- wontfix
firefox71 --- fixed


(Reporter: mstange, Assigned: gerald)


(Blocks 2 open bugs)



(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.

Type: defect → enhancement

Part of this work should also be reviewing and combining the many JS sampling related options; based on use cases and overhead.

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

Right, I was thinking about the power overhead of the wakeups. But yes, we can make all of those levers independent.

Priority: -- → P3
Depends on: 1562604

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

Assignee: nobody → gsquelart
Blocks: 1583430
Blocks: 1583431
Pushed by
Rudimentary no-sampling mode - r=gregtatum
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1583868
Blocks: 1599338
You need to log in before you can comment on or make changes to this bug.