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.

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.

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.

[Neurotoxin001]

I noticed same thing on twitter, dropdown menu items like retweet / "moar" settings etc is become laggy (after every page refresh). But all becomes fine after I enable "Ignore Generic Cosmetic Filters" on chrome 98.0.4758.102

[gorhill]

@Neurotoxin001 Without disclosing which cosmetic filters are active on Twitter, this is not useful -- your issue could be that you are using poorly crafted cosmetic filters on Twitter, I see these commonly being suggested in various forums or even on Twitter. To increase usefulness of you comment, please report troubleshooting information from Support pane in the dashboard.

[Neurotoxin001]

Troubleshooting information

uBlock Origin: 1.41.2
Chromium: 98
filterset (summary): 
  network: 131233
  cosmetic: 156517
  scriptlet: 34797
  html: 0
listset (total-discarded, last updated): 
  removed: 
    plowe-0: null
    urlhaus-1: null
  added: 
    https://easylist-downloads.adblockplus.org/bitblock.txt: 30051-15523, 19h.33m
    https://easylist-downloads.adblockplus.org/cntblock.txt: 1383-45, 19h.33m
    adguard-annoyance: 50354-2607, 19h.33m
    adguard-generic: 61936-1250, 19h.33m
    adguard-mobile: 7232-83, 19h.33m
    adguard-social: 15806-2257, 19h.33m
    adguard-spyware: 25691-1122, 19h.33m
    adguard-spyware-url: 488-24, 19h.33m
    block-lan: 44-0, 19h.33m
    fanboy-annoyance: 60311-38697, 19h.33m
    fanboy-thirdparty_social: 69-21, 19h.33m
    ublock-annoyances: 4404-302, 19h.33m
  default: 
    user-filters: 146-1, never
    RUS-0: 41416-997, 19h.33m
    easylist: 63637-24742, 19h.32m
    easyprivacy: 26560-11333, 19h.32m
    ublock-abuse: 77-1, 19h.32m
    ublock-badware: 3965-240, 19h.32m
    ublock-filters: 30199-3578, 19h.32m
    ublock-privacy: 202-41, 19h.32m
    ublock-unbreak: 1716-113, 19h.32m
filterset (user): [array of 145 redacted]
trustedset: 
  added: [array of 1 redacted]
switchRuleset: 
  added: [array of 1 redacted]
modifiedUserSettings: 
  advancedUserEnabled: true
  uiTheme: light
  ignoreGenericCosmeticFilters: true
  showIconBadge: false
  suspendUntilListsAreLoaded: false
  tooltipsDisabled: true
modifiedHiddenSettings: [none]
supportStats: 
  allReadyAfter: 534 ms (selfie)
  maxAssetCacheWait: 513 ms

I tried to test this by disabling the filter lists one by one but I still can't catch which one is causing this. Because it's "laggy" not much but still noticable while using Twitter. And maybe not only one filter list have the problematic rule.

I only have these filters in uBlock logger:
https://imgur.com/a/umVnA7B