Timer initialization in BackgroundHangThread::NotifyActivity adds very high overhead to task handling
Categories
(Core :: XPCOM, 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?
Updated•2 years ago
|
Comment 1•2 years ago
|
||
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.
Comment 2•2 years ago
|
||
(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/3eCkJdPDo 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.
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
Description
•