Open Bug 1796080 Opened 2 years ago Updated 2 years ago

Timer initialization in BackgroundHangThread::NotifyActivity adds very high overhead to task handling

Categories

(Core :: XPCOM, defect)

defect

Tracking

()

Performance Impact low
Tracking Status
firefox-esr102 --- unaffected
firefox106 --- disabled
firefox107 --- disabled
firefox108 --- fix-optional

People

(Reporter: smaug, Unassigned)

References

(Regression)

Details

(Keywords: regression)

When profiling the third test of MotionMark (leaves), one can see BackgroundHangMonitor adding high overhead.
https://share.firefox.dev/3eCkJdP

Do we end up re-initializing the timer for each task or what?

Set release status flags based on info from the regressing bug 965392

:florian, since you are the author of the regressor, bug 965392, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #0)

When profiling the third test of MotionMark (leaves), one can see BackgroundHangMonitor adding high overhead.
https://share.firefox.dev/3eCkJdP

Do we end up re-initializing the timer for each task or what?

Looks like it. In less than 700ms (https://share.firefox.dev/3S7DG5L) we call NotifyActivity almost 12000 times. We could avoid re-initializing the timer when the already called NotifyActivity less than 1ms ago (there would still be the cost of TimeStamp::Now()).

Also, most of the time in the overhead you noticed is actually the overhead of adding the profiler markers: https://share.firefox.dev/3Tg1lCa, so the overhead when the profiler is not running should be significantly lower.

Note: BHR is only enabled on Nightly.

Performance Impact: ? → low

Marking as S3 as BHR is nightly-only.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.