High amount of overhead from capturing and freeing cause callstacks for refresh driver ticks
Categories
(Core :: Gecko Profiler, defect, P2)
Tracking
()
People
(Reporter: mstange, Unassigned)
References
(Depends on 1 open bug)
Details
In bug 1656331 I added instrumentation to the refresh driver that captures callstacks in EnsureTimerStarted. This seems to have surprisingly high overhead. Here's a profile in a scenario with 10 animating windows, where we capture around 500 stacks per second: https://share.firefox.dev/2Ccjkr4
A lot of time is spent waiting in profiler locks.
The profile is from bug 1636337 comment 24.
Looking at the profiler overhead (in microseconds, "ns" is wrong, see https://github.com/firefox-devtools/profiler/issues/2603 ), 69% of the time is spent in the locked sampling loop, which takes ~1.8ms on average, so it's no surprise that profiler_get_backtrace() may take a while to get its turn!
Regarding the time spent in profiler locks, I think bug 1651259 is relevant (trying not to use locks in profiler_get_backtrace() if possible).
We also have bug 1578792 to try and remove allocations, and at the moment I'm implementing bug 1658232, which removes at least one (small) allocation in all cases, and will get rid of most allocations when using the new markers API.
Are there any other sources of overhead these bugs would not cover?
In the meantime, if you want to have such high-frequency markers with stacks, you could try the "No Periodic Sampling" option, or at least reduce the sampling frequency.
|
Reporter | |
Comment 2•5 years ago
|
||
Are there any other sources of overhead these bugs would not cover?
No, I think those are all the ones that I see in these profiles. Good.
Description
•