-
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. |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 6 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
They are pretty much the same for me |
Beta Was this translation helpful? Give feedback.
-
That's not how mv2/mv3 frameworks work. |
Beta Was this translation helpful? Give feedback.
-
On HP laptop Ryzen 5700U with 16GB RAM and 1 TB SSD on Linux Mint Cinnamon Also on my Wife's laptop Windows 11 (HP laptop with Ryzen 4600U with 16GB Ram and 512 GB SSD) 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. |
Beta Was this translation helpful? Give feedback.
-
Actual real world cases is what drive development, not synthetic benchmarks. See https://github.com/gorhill/uBlock/wiki/Scientific-papers#other-helpful-reference-materials.
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. |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
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 Content blocker A: Content blocker B And when you zoom on the mutation observer related work: Content blocker A: Content blocker B: So imagine someone claims that Content blocker B is more efficient solely based on the And even the above full picture leaves out a lot of important factors such as:
|
Beta Was this translation helpful? Give feedback.
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…