Use UBlockLight MV3 static filtering for uBlockOrigin MV2

[Kees1958]

This is something anyone can check on Firefox by running Speedometer 3.0 with Adguard in default against uBO in default.

https://browserbench.org/Speedometer3.0

The score of AdGuard is considerably higher (even ABP beats uBO in Speedometer 3.0 test). On Chrome uBO-light scores the same as AdGuard.

Idea I would propose: use the static filtering of uBO-light (which moves much of the heavy lifting to the browser itself) for performance improvement and only use the dynamic filtering engine of uBO Mv2.

[gwarser]

Please try with cosmetic filtering turned off - https://github.com/uBlockOrigin/uBlock-issues/wiki/Per-site-switches#no-cosmetic-filtering

This may be the result of how uBO cosmetic filtering engine work to reduce memory usage.

[garry-ut99]

How will that be a fair comparison then? Since to be fair, cosmetic filtering should be disabled in all extensions (or in none extensions)?

[stephenhawk8054]

They are pretty much the same for me

[uBlock-user]

That's not how mv2/mv3 frameworks work.

[Kees1958]

On HP laptop Ryzen 5700U with 16GB RAM and 1 TB SSD on Linux Mint Cinnamon
Ungoogled uBOL = 12,4 AG=12,7, uBO=11,3 on average
Firefox AG = 15,1 uBO = 13,7 on average

Also on my Wife's laptop Windows 11 (HP laptop with Ryzen 4600U with 16GB Ram and 512 GB SSD)
Firefox AG = 14,2 uBO = 12,4 on average

Because I noticed it on two laptops with different OS, I thought it would be common, the consistent factor is the HP brand with Ryzen, maybe that is the cause of the performance drop.

Windows laptop (Microsoft Office plus Edge as primary and Chrome as secondary browser) and Linux laptop (Only Office with Firefox as primary and Ungoogled as secondary browser) are nearly vanilla setups.

[garry-ut99]

I'm not sure whether Speedometer 3 is a proper tool to measure performance between ad-blocking extensions, anyway just replying to your comment:

Kees1958 : the consistent factor is the HP brand with Ryzen, maybe that is the cause of the performance drop.

Doesn't seem so, my results confirm your results, that uBO has the lowest score on Speedometer 3 (Intel Core i7 Haswell):
Firefox: uBO 11.4, uBOL 11.7, AG 11.8, no extension 11.9
Chromium: uBO 12.1, uBOL 13.4, AG 13.3, no extension 13.5

Here are the same results presented as relative speed (in %), to the top result (13.5) = 100%
(which means the chart is useful to compare not only results difference between extensions but also between browsers):

---

UPDATED: I did also tests with JetStream 2 benchmark, results in Firefox are similiar to Speedometer 3 - uBO loses, but in Chromium, uBO surprisingly wins:

Firefox: uBO 117.923, uBOL 122.506, AG 122.862 no extension 124.233
Chromium: uBO: 152.237 uBOL 149.013, AG 149.434 no extension 148.883

[gorhill]

Actual real world cases is what drive development, not synthetic benchmarks. See https://github.com/gorhill/uBlock/wiki/Scientific-papers#other-helpful-reference-materials.

---

Idea I would propose: use the static filtering of uBO-light (which moves much of the heavy lifting to the browser itself)

This is wrong. The cosmetic filtering of MV3 is not better than the cosmetic filtering of MV2, the declarativeNetRequest API has nothing to do with cosmetic filtering. Speedometer is not affected by DNR. Also, Speedometer doesn't measure memory efficiency, it measures a narrow aspect of a content blocker, not how fast webpages load, and how much memory your webpages consume.

[garry-ut99]

Yes, OP should follow:

Speculated performance issues will be marked as invalid and closed if they do not come with actual profiling data from the Firefox Profiler/Chromium Profiler and a fully substantiated analysis supporting the claim.

and also should "not submit revolutionary ideas":

Kees1958 : Idea I would propose: use the static filtering of uBO-light (which moves much of the heavy lifting to the browser itself) for performance improvement and only use the dynamic filtering engine of uBO Mv2.

• https://github.com/gorhill/uBlock/blob/d75a1582ef3cff6644a7e87530ea9bda41af62e3/CONTRIBUTING.md#before-you-submit :

Do NOT Submit "revolutionary ideas".

By the way, OP should also read (if didn't read yet): "uBlock's resource usage and efficiency" section of uBO documentation (some things might be old, but still contain much useful information):

And "Tools/tests" section:

• https://github.com/gorhill/uBlock/wiki/Tools

And also uBOL documentation as well:

• https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#is-ubol-more-efficient-cpu--and-memory-wise-than-ubo

And some related (invalid/external) threads:

• Performance regression Lite vs no extension uBOL-home#73
• Performance of UBOL decreased significantly on Chromium 124 uBOL-home#123

[Kees1958]

@garry-ut99 thanks for testing

@gorhill According to browserbench,org "Speedometer is a browser benchmark that measures the responsiveness of Web applications. It uses demo web applications to simulate user actions such as adding to-do items."

Because Google used the performance argument to drop Webrequest I am not surprised Mv2 content blockers are slower than Mv3 content blockers.

[Yuki2718]

Because Google used the performance

Which was completely disproven by Ghoetery with real-world benchmark, after which the big G turned to focus on security which is also disproven in multiple ways. It is only in theory that MV3 improves performance, the reality is it's totally up to extensions as shown in DebugBear benchmark mentioned also in https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#is-ubol-more-efficient-cpu--and-memory-wise-than-ubo. Note the current DNR doesn't even tokenize regex by itself.

[gorhill]

There is no proof yet that "Mv2 content blockers are slower than Mv3 content blockers", that is not the purpose of Speedometer.

Anyway, I won't argue further about this, you obviously do not trust that I know what I am doing, so I just suggest you move on and use AdGuard instead of keeping opening discussions about what I should do with uBO Lite.

[garry-ut99]

Kees1958: (...)

There also was much discussion about "performance" argument in the big thread:

• Chrome extension manifest v3 proposal #338

---

By the way, I've updated my previous comment: #3383 (reply in thread) with tests on another benchmark: JetStream 2, results in Firefox are similiar to Speedometer 3 - uBO loses, but in Chromium, uBO surprisingly wins. (and again - I'm aware they are just synthetic benchmarks, but I was just curious what results will be shown by another synthetic benchmark).

[gorhill]

Typically an extension which uses a mutation observer in its content scripts will "lose" in Speedometer over one that doesn't -- usage of a mutation observer, even a noop, affects Speedometer results, especially for some very specific frameworks used in Speedometer. In Complete mode, uBOL requires a mutation observer. In Optimal mode, no mutation observer is used unless there are procedural cosmetic filters to apply.

However a mutation observer in a content blocker represents a fraction of all the work done by the blocker, so focusing on Speedometer results to judge a content blocker means focusing on that fraction of work to judge the whole efficiency the content blocker, which of course leads to flawed conclusions. This is what is happening here.

To better illustrate the flawed approach of using Speedometer to judge content blocker efficiency, let's say y is CPU usage related to usage mutation observer, and x is all the other work required by the content blocker to perform its duty:

Content blocker A:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxyy

Content blocker B
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxy

And when you zoom on the mutation observer related work:

Content blocker A:
yyyyyyyyyyyyyyyyyyyy

Content blocker B:
yyyyyyyyyyyyyyyyyy

So imagine someone claims that Content blocker B is more efficient solely based on the y part of the content blocker. This is what is happening here.

And even the above full picture leaves out a lot of important factors such as:

• Which content blocker has the service worker with the smallest memory footprint?
• Which content blocker has the service worker with the least CPU usage?
• Which content blocker has the service worker which initializes the fastest?
• Which content blocker filters more reliably? (at either browser start or service worker re-launch)