User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Loading a page with 10k+ lines (tab rows really) in OpenGrok (https://github.com/oracle/opengrok/) makes the page loading times jump to the range of tens of seconds on some systems. Using Firefox Profiler most of the time was spent in the CoalesceMutationEvents() function. While the amount of events generated by the page could be lowered, the function should not take seconds to complete.

More details (including Firefox Profiler JSON files, images of profiler graphs, analysis of the stack that lead to the function being called, etc.) can be found on https://github.com/oracle/opengrok/issues/3032

Actual results:

page too tens of seconds to load/render

Expected results:

should take bunch of seconds max

Jamie, what priority is this? Does this give us some leads with regards to slow tables and other similar issues we've been having with slow loading big pages?

(In reply to Marco Zehe (:MarcoZ) from comment #1)

Jamie, what priority is this? Does this give us some leads with regards to slow tables and other similar issues we've been having with slow loading big pages?

My understanding is that while this is indeed very nasty, this particular kind of perf issue isn't common. The other issues we have regarding slow loading pages are more about the screen reader building of virtual buffers (i.e. clients making a huge number of a11y calls). In contrast, this bug is about Gecko coalescing a11y events; i.e. there doesn't even have to be a screen reader buffer in play to trigger this.

Giving this p2 for now because it's nasty but uncommon.

Probably related to bug 1368784 and/or bug 1414918.

This is profile from a system where it took some 19 seconds to display a page (HTML representation of a C source file with some 11K LOC)

A profile that captures the load of the same page as the previous profile, albeit on different platform. It does not exhibit the performance problem because interestingly, I don't see any a11y calls there even though it is running same version.

Is there perhaps a workaround ?

Unfortunately, beyond reducing the number of mutations, I don't think there's a workaround at this point. :(

When adding a new accessibility event to NotificationController, we
check to see if the event should be suppressed. This is a time-memory
tradeoff; since we check every event before dispatching them, the
correctness should not be impacted regardless of whether we always
append events. This change takes the time required from O(mn^2) where m
is the average depth of an event's parent tree and n is the number of
events, to O(mn).

https://hg.mozilla.org/mozilla-central/rev/64ae8c433b04

Backed out from Beta for causing topcrash bug 1749633. It's still landed for 98+ but we should revisit that if we can't get to the bottom of bug 1749633 in the next couple weeks.
https://hg.mozilla.org/releases/mozilla-beta/rev/05fbafbb07a8

Backed out from Beta 98 again for causing topcrash bug 1749633.
https://hg.mozilla.org/releases/mozilla-beta/rev/94314208d19d1f990646ca3a67c8b17bdf2d88c4