https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&hidelog=1&limit=250&days=14&urlversion=2&damaging=maybebad&damaging__likelybad_color=c3&damaging__verylikelybad_color=c4&goodfaith__verylikelybad_color=c5&highlight=1 spends 2.5 seconds on startup because highlighting is very slow. 80+% of the time spent is in dm.FiltersViewModel#toggleHighlight and functions it calls. 43% of the time is spent in Sizzle, called from .find(), presumably with strange selectors. 14% is spent in querySelectorAll, also from .find().
|mediawiki/core : wmf/1.31.0-wmf.1||Reapply "RCFilters: Don't apply/clear highlights 66 times"|
|mediawiki/core : master||Reapply "RCFilters: Don't apply/clear highlights 66 times"|
|mediawiki/core : master||RCFilters: Don't apply/clear highlights 66 times|
|mediawiki/core : wmf/1.31.0-wmf.1||RCFilters: Don't apply/clear highlights 66 times|
|Resolved||DannyH||T171977 Annual Plan 2017-2018, Audiences 5: Increase current editor retention and engagement|
|Resolved||DannyH||T171981 Annual Plan 2017-2018, Audiences 5, Goal 2: Give better ways to monitor contributions|
|Resolved||• jmatazzoni||T157642 Graduate New Filters UX out of beta on Recent Changes on ALL wikis|
|Resolved||Krinkle||T176652 Performance review of RCFilters feature|
|Resolved||Catrope||T177107 Highlighting many changes at init time is very slow|
I misdiagnosed this a little: yes, the highlights code is somewhat inefficient and could be optimized a bit to use .find() less, and in other ways, but the main problem was that on init we were applying highlights 66 times (and clearing them 64 times). The attached patch reduces this to just two, which is still one too many, but it's already a lot faster.
Checked in betalabs and cawiki (1.31.0-wmf.2) - no delays with highlighting. However, when there 1,000 changes in 30 days options are selected, the improvement is not noticeable; the range for the page load time increases significantly to avg 17-24s.