Performance: Large uptick in Chrome "Recalculate Styles" time spent. V1.41.2.

[scottschiller]

Prerequisites

• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• using a new, unmodified browser profile

Description

Firstly, thanks for this. I won't use a browser without it. 🙇‍♂️

I have a few old-school "DHTML"-style games that create and move lots of DOM nodes around. I spend a fair bit of time on performance in Chrome's Dev Tools trying to optimize paint, style recalc, layout operations etc.

My latest game just recently took a performance hit, showing lower frame rates. I noted a sharp increase in time spent in "Recalculate Styles." I thought I had broken something in dev, but I realized my production version and older versions were all taking a hit as well. Same for another game I made in 2012 that uses lots of DOM nodes: recalc style times were way up.

Between disabling extensions and uBlock's filtering, this performance change appears to be connected to uBlock Origin being enabled and with cosmetic filtering active for the current site.

I was seeing this in Chrome and Chrome Canary, and I think it started within the last few days. FWIW, I didn't seem to see this in Firefox Nightly. I'm on a 2018 Mac Mini, 3.2 GHz 6-core IC7, 32 GB, Mac OS 12.2.1.

From Chrome Dev Tools, Recalc Styles timings are typically 7 msec or less, and "elements affected" may be e.g., 140.
Screenshots here from Chrome Canary 100.0.4886.0.

This is with uBO disabled. Performance is reasonable, albeit some overhead in recording the profile.

uBO enabled. 60+ msec timings, and the reported "elements affected" can be way up, 400+ at times(!?) 🤔 😰

Hopefully this can be reproduced, and I'm not just seeing things. 😅 🤞

A specific URL where the issue occurs

http://schillmania.com/armor-alley/

Steps to Reproduce

1. In Chrome, load up http://schillmania.com/armor-alley/ with "uBO" enabled and active.
2. Choose "Extreme mode" from the game menu.
3. Open Chrome Dev Tools, and start recording a performance profile (no screenshots, memory or web vitals needed.)
4. Fly the helicopter up to the right, and an anti-aircraft turret will fire lots of bullets, creating a lot of DOM node churn. 😅
5. If correct, game performance should take a hit (dropping frame rate, etc.) as DOM nodes increase.
6. Stop recording and inspect the performance profile, noting time spent in tasks and with attention to "Recalculate Styles."
7. Disable cosmetic filtering (or uBO entirely), reload the page, and repeat profile + test as in steps 3 and 4.
8. With filtering / uBO disabled, performance should be smoother.

Expected behavior

The game should be reasonably smooth and performant, targeting 30fps in a windowed desktop browser tab.
"Recalculate Styles" should be faster in Chrome Dev Tools, ideally under 5 msec. "Elements affected" may be over 100.

I made a walk-through of a recent round of updates, including performance improvements; this is how it should ideally run.
https://youtu.be/9BQ62c7u2JM

Actual behavior

With uBO active: As gunfire and other elements are created and updated in the DOM, performance is impacted by a significant increase in time spent in "Recalculate Styles" - I'm seeing 50-60 msec, sometimes more. The "Elements Affected" seems to be amplified here, sometimes 400+. (Is there some sort of node cloning going on??)

Chrome Dev Tools (Canary 100.0.4886.0) profiles .json files, which the screenshots are of:

aa-uBO-disabled.json.zip
aa-uBO-enabled.json.zip

Configuration

The below is from my existing uBO set-up, but I tested and confirmed the issue with a brand-new browser profile and default uBO install. I apologize if this is not the relevant data, and am happy to revisit if it will help in troubleshooting.

uBlock Origin: 1.41.2
Chromium: 100
filterset (summary):
network: 77420
cosmetic: 41125
scriptlet: 16434
html: 0
listset (total-discarded, last updated):
default:
user-filters: 6-0, never
easylist: 63376-9, 1h.7m
easyprivacy: 26556-120, 1h.6m
plowe-0: 3679-807, 3d.14h.39m
ublock-abuse: 77-0, 1h.5m
ublock-badware: 3940-76, 1h.3m
ublock-filters: 30249-138, 1h.2m
ublock-privacy: 200-2, 1h
ublock-unbreak: 1715-39, 1h.1m
urlhaus-1: 6525-0, 59m
filterset (user): [array of 6 redacted]
modifiedUserSettings: [none]
modifiedHiddenSettings: [none]
supportStats:
allReadyAfter: 171 ms (selfie)
maxAssetCacheWait: 155 ms

[scottschiller]

Something I just noted in the profiles: With uBO enabled, the long "recalc style" blocks have a ton of data requests for base64 image URLs underneath them - and there is a lot of network activity for these which isn't present in the uBO disabled profile.

These URLs are for sprites used in the game, applied as background images via CSS.

[mateuszkozakiewicz]

I have noticed this problem as well, it exists for huge blocks of text in Github or Gitlab, the performance hit is extreme on any hardware in Chromium based browsers.
You can fix it by disabling Parse and enforce cosmetic filters in Filter lists in uBlock Origin settings.

[gwarser]

This is known for pages with large amount of nodes, like large diffs on GitHub. What can be worrying is possible regression in performance in latest builds.

Profile-20220215T191440-1.40.8.zip
Profile-20220215T191536-1.41.2.zip
Profile-20220215T192148-1.41.2.no-cosmetic-filtering.zip

Does not seem very bad on my side. I feel that test in game is too random.

Tested after reset to default and update all filters. 1.40.8 is a local build.

[gwarser]

You can fix it by disabling Parse and enforce cosmetic filters in Filter lists in uBlock Origin settings.

You can turn off cosmetic filtering only for affected page by "No cosmetic filtering" switch in popup.

[mateuszkozakiewicz]

You can turn off cosmetic filtering only for affected page by "No cosmetic filtering" switch in popup.

This is true however problem exists on most websites. While scrolling through comments on social media posts the occasional hitching is not a big deal on large diffs in Gitlab or some dev tools I use daily like ArgoCD which also produce many nodes I would describe the experience as unusable or broken.

[scottschiller]

@gwarser Thanks for the profiles, those are interesting. Looks like you have maybe a 5X increase in "Recalculate Style", but the game is still performant with most frames under 16 msec in your 1.40.8 file.

I apologize as the game is certainly not an ideal / isolated test case, but I think the profiles suggest a possible performance regression. I will poke around and follow up if I can create a good isolated test that shows similar recalc style timings.

[scottschiller]

The "FAT" (Fast Animation Tool) library has a demo page which could be a good test candidate, moving a bunch of balls around the screen. https://github.com/nextapps-de/fat - and demo page: https://nextapps-de.github.io/fat/

With the default settings (1500 / Animate / FAT), per the demo's own stats UI, I get ~45 FPS with uBO off and ~11 with it on in Chrome. Whether "animate" (setting top/left I think), "transform" (GPU) or "color", performance drops similarly.

[gorhill]

Off the top of my head, most likely explanation is that in 1.41.0, every highly generic cosmetic filters is now wrapped into a :is(...):not(html,body), to address #1692.

[gorhill]

Maybe I should back out the changes for the above issue, I feel the same change is responsible for issues reported in older Firefox versions.

[gorhill]

See if dev build 1.41.5b1 or above helps -- most likely the reverted change was the culprit. Chrome store takes a while before publishing latest dev build, so 1.41.5b1 might not be available there before a few days.

[trishankkarthik]

Was especially the case on Twitter from my experience, especially with what seems to be a large, obfuscated number of DOM nodes.

[gorhill]

On my side, I didn't see obvious performance degradation with Twitter, but I have not added extra filter lists which contain highly generic cosmetic filters -- quite probably adding such lists (i.e. Fanboy Annoyances, AdGuard Annoyances, AdGuard Social, maybe some regional lists) would make the regression more noticeable.

[scottschiller]

Testing 1.41.5b1, I'm seeing an improvement vs. 1.41.4. The prior "Fast Animation Tool" demo page may be a decent stress test for performance, comparing with uBO / cosmetic filtering enabled vs. disabled.

Testing with 1.41.5b1, I get ~40 FPS using default settings on the FAT demo page w/UBO disabled, 27.5 when enabled in Chrome.

With the prior 1.41.2 release, ~40 FPS and 10.8 FPS, respectively. I can provide profiles if that'd be useful.