Longer time-to-readiness with Chromium 110

[gorhill]

I notice a steep regression in time-to-readiness starting with Chromium 110.

I can see this on my side and this appears to be confirmed by looking at Support => allReadyAfter for numerous filter issues with Chromium 110 being mentioned. This has to be a change in Chromium itself, since any previous version of Chromium do not systematically report 3000+ ms for allReadyAfter despite the same uBO version being used.

This means there could be an uptick in reports of Youtube video ads not being blocked or similar cases at browser launch.

[stephenhawk8054]

Do we have any performance measuring tools to see what processes are taking time for the time-to-readiness like profiler?

[gorhill]

I can't pinpoint exactly where in Chromium the exact regression is performance-wise, but from what I have observed it does look like it's browser.storage-related. The regression in time-to-readiness occurs only at browser launch, i.e. it does not occur if you manually start uBO after the browser is already launched, in which case I get a time-to-readiness of 125 ms (selfie), while I am currently getting over 2000 ms (selfie) at browser launch -- despite the exact same sequence of code being executed.

[stephenhawk8054]

Do you see the same slowness with other extensions (especially other blockers...)? I suspect if this affects extensions in general, users who use more extensions will feel the slow starting more obviously (currently my chromium browser only has uBO and I haven't seen the slowness to the point of over 10000ms like in some issues reported).

---

Or it might relate to history/storage as my chromium is just used for testing, not for real using.

[gorhill]

Do you see the same slowness with other extensions (especially other blockers...)?

I see the same behavior in AdGuard and ABP. My test is to load https://arstechnica.com/ in a tab, quit the browser, then launch the browser with that tab active. With any blockers, you can see that the block count keeps climbing, because the ad/tracker scripts were not actually blocked and these causes a lot of requests to be blocked once the blocker is fully initialized, even though cosmetically all seem to be blocked. If you force a reload of the page when you think the extension is fully initialized, then the block count should stay stable in the low 2-digit.

[uBlock-user]

https://www.reddit.com/r/uBlockOrigin/comments/11fj3fa/ublock_takes_long_time_to_load/

allReadyAfter: 249271 ms

[ghost]

https://www.reddit.com/r/uBlockOrigin/comments/11gkra9/ublock_takes_time_to_work/

[uBlock-user]

He didnt mention Chromium version. The issue here is specific to 110 only.

[dportvine]

allReadyAfter: 282776 ms (selfie), maxAssetCacheWait: 16459 ms #18464

[gorhill]

That person was subscribed to tons of lists, including some which are no longer in existence (try https://gitcdn.xyz/repo/NanoAdblocker/NanoFilters/master/NanoFilters/NanoBase.txt in browser), unresponsive server is what caused this issue.

[u-RraaLL]

Should there be an announcement made about this on reddit maybe? Should we advise people to downgrade to 109?

Has anybody tested if the issue persists into 111-113?

[gorhill]

Should we advise people to downgrade to 109

Never should we advise to not upgrade to latest version.

[krystian3w]

On Windows 7, chromium 110+ needs hacks to run.

[dportvine]

Has anybody tested if the issue persists into 111-113?

Details

uBlock Origin: 1.47.4
Chromium: 111
filterset (summary): 
  network: 102872
  cosmetic: 129552
  scriptlet: 23801
  html: 0
listset (total-discarded, last-updated): 
  removed: 
    urlhaus-1: null
    plowe-0: null
  added: 
    https://easylist-downloads.adblockplus.org/bitblock.txt: 31568-26, 1h.10m
    https://easylist-downloads.adblockplus.org/cntblock.txt: 1551-26, 1h.10m
    https://www.awwwwesome.org/url-blocklist/url-blocklist.txt: 773-0, 1h.10m
    fanboy-cookiemonster: 45993-386, 1h.10m
    ublock-annoyances: 4845-52, 1h.10m
  default: 
    user-filters: 1-0, never
    ublock-filters: 32875-41, 1h.10m
    ublock-badware: 4640-0, 1h.10m
    ublock-privacy: 289-7, 1h.10m
    ublock-abuse: 78-0, 1h.10m
    ublock-unbreak: 1909-11, 1h.10m
    ublock-quick-fixes: 362-36, 1h.10m
    easylist: 63562-223, 1h.10m
    easyprivacy: 31023-1510, 1h.10m
    RUS-0: 39481-303, 1h.10m
filterset (user): [array of 2 redacted]
modifiedUserSettings: 
  advancedUserEnabled: true
  contextMenuEnabled: false
  showIconBadge: false
modifiedHiddenSettings: 
  cacheStorageAPI: indexedDB
  filterAuthorMode: true
  popupPanelHeightMode: 1
supportStats: 
  allReadyAfter: 3274 ms (selfie)
  maxAssetCacheWait: 536 ms
popupPanel: 
  blocked: 54
  blockedDetails: 
    github.com: 51
    google.com: 2
    translate.googleapis.com: 1

[gorhill]

I made changes in 1.47.5b2 which should help diagnose uBO's "unreadiness" at launch:

• At browser launch, uBO's toolbar icon will be yellow until it is ready to filter
• The number of unprocessed network requests at launch will be reported in troubleshooting info

[krystian3w]

Currently, ABP and AdBlock are driven by the same engine (~3 years), that if something doesn't work in one, it also doesn't works in the other if based on engine.

---

After an additional description, I now know how to look to notice color differences when they do not start with yellowish.

[gorhill]

Would it be possible to start the extension in yellow

The browser picks the toolbar icon from the manifest before uBO is actually launched. Only after uBO is launched it can control the toolbar icon color. I did try to set the manifest default toolbar icons to yellowish unready ones, I still still the color changing back and forth at launch. For now we will have to live with this, I might look into this more in the next dev cycle.

[vlaszlo]

Thanks.

[uBlock-user]

still still the color changing back and forth at launch. For now we will have to live with this, I might look into this more in the next dev cycle.

All extensions icons are cached post installation. So to see new changes, that icon cache will need to be evicted too first.

[gorhill]

In that case if setting the not-ready icons by default, this could lead to an issue of the not-ready icon being used by the browser when merely opening a new tab, the same way the current default icon is used when opening a new webpage for which uBO is disabled or for priviledge pages. That would be worse than what we have now.

[ghost]

Wondering if this is related to filter lists load time or to something else.

Chrome (pretty clean):

[uBO] Admin settings ready 2830 ms after launch
[uBO] Backend storage for cache will be browser.storage.local
[uBO] Hidden settings ready 2838 ms after launch
[uBO] Extra admin settings ready 2839 ms after launch
[uBO] List selection ready 2839 ms after launch
[uBO] Cache magic numbers ready 2839 ms after launch
[uBO] First fetch ready 2842 ms after launch
[uBO] User settings ready 2844 ms after launch
[uBO] PSL ready 2852 ms after launch
[uBO] loadFilterLists() took 190 ms
[uBO] Filter lists ready 3130 ms after launch
[uBO] All ready 3131 ms after launch

Firefox (my dirty profile):

[uBO] Admin settings ready 26 ms after launch
[uBO] Backend storage for cache will be indexedDB
[uBO] Hidden settings ready 41 ms after launch
[uBO] Extra admin settings ready 44 ms after launch
[uBO] WASM modules ready 46 ms after launch
[uBO] List selection ready 60 ms after launch
[uBO] WASM PSL ready 61 ms after launch
[uBO] First fetch ready 64 ms after launch
[uBO] User settings ready 73 ms after launch
[uBO] Cache magic numbers ready 114 ms after launch
[uBO] PSL ready 124 ms after launch
[uBO] Selfie ready 343 ms after launch
[uBO] All ready 344 ms (selfie) after launch

[gorhill]

That's not a solution, that will cause other problems we identified in the past when trying to use indexedDB in Chromium.

I will just add code to cache the content of storage.managed into storage.local and uBO will use this at launch time. storage.managed will still be called, but not in a blocking manner, and just to cache the content into storage.local for the next time uBO launches.

[uBlock-user]

Yes, that's why I said "workaround" this issue until a proper solution appears.

[ghost]

This fixes video ads on startup on YT for me 10 times out of 10 trials. And this without "Suspend network activity". Tried on https://www.youtube.com/watch?v=LcmT38ZPTjg. Good change. But now admins will complain about one more restart before policies will be active.

[stephenhawk8054]

@gorhill @gwarser Should we add a line in release announcement for warning the admins when updating to new version?

[gorhill]

We don't know if it will be different than before. For all I know, maybe the regression in Chromium 110 is because they fixed the storage.managed issue of having to restart, and me adding code to require this just bring back things as they were. We will have to wait for reports.

[uBlock-user]

1.47.5rc5 now throws an error in Nightly extension console --

[uBlock-user]

I see it everytime I disable and then enable the extension. Last good build was 1.47.5rc2.

[ghost]

It's because I have actual manifest with benchmarkDatasetURL set.

[uBlock-user]

I have actual manifest

???

[gorhill]

See if this is fixed in 1.47.5rc6.

[uBlock-user]

Yep, back to normal with rc6.