uBlock Origin performance improvements thanks to WASM (Firefox only, for now)
The most recent version of the content blocking extension uBlock Origin uses WebAssembly (WASM) code to improve the performance of the extension.
The new uBlock Origin 1.17.4 is already available on the GitHub project website and Google and Mozilla web stores for extensions.
The new versions get pushed out to users in a rolled released which means that you may not get it immediately. Chrome and Firefox users may enforce the update. Chrome users may want to read how to update Chrome extensions manually for information on how that is done, Firefox users may check this guide instead.
Raymond Hill (gorhill) notes that the new code is only active in the Firefox extension and not in the extension for Google Chrome. The reason for that is that Google Chrome does not allow wasm "without adding 'unsafe-eval' to the extension's own Content Security Policy in its manifest" which Raymond considers unsafe for use).
Firefox users who run the latest version of the extension already can run a benchmark to find out how well it performs in comparison to the algorithm that does not use WASM.
Open the benchmark in the browser and select Lookup to find out how well it performs. Compare the last two lines for that. The example above shows that the WASM version runs about a 1000 operations per second more than the previous version of the algorithm.
Gorhill plans to introduce WebAssembly versions of "key portions of code" if it is of benefit to the extension. Expect uBlock Origin to perform better in browsers that support it; whether the performance gains are large enough to be noticeable by users remains to be seen but they could certainly make the difference in some scenarios.
You can find out more about WebAssembly on the official project website. It is supported by Firefox, Chrome, Safari and Microsoft Edge (and browsers based on code of those four). The code that uBlock Origin uses is available here.
Now You: Which content blocker do you use, and why?
wow waterfox feels a lot faster now, thanx
When I try to install 1.17.4 from Github I get the warning that “Firefox prevented this site from installing an unverified add-on.”
(I noticed that this version’s file is called “uBlock.firefox.xpi” while version 1.17.3 is called “uBlock.firefox.signed.xpi”.)
That version is not signed, you need to install the version on Mozilla AMO: https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
thanks, you’re right. I could and should have known.
Must be the monday morning blues…
Install the on called firefox.signed.xpi, not firefox.xpi, that’s the unsigned one and a stable version.
Hmm, I’m on Firefox with uBlock Origin, but this benchmark doesn’t work for me.
Test 100 needles against 16 dictionaries of hostnames and nothing more, there are no lines. I don’t know why.
@Nelle: exactly the same for me.
@Nelle
What you need to do is just to click the Lookup button and wait:
Test 100 needles against 16 dictionaries of hostnames
– Set-based x 1,191 ops/sec ±2.66% (5 runs sampled)
– Regex-based x 2,133 ops/sec ±2.38% (5 runs sampled)
– Trie-based (1st-gen) x 6,256 ops/sec ±3.90% (5 runs sampled)
– Trie-based JS (2nd-gen) x 5,869 ops/sec ±3.41% (5 runs sampled)
– Trie-based WASM (2nd-gen) x 7,578 ops/sec ±3.50% (5 runs sampled)
Done.
BTW, people who deployed the ghacks’ user.js will need to set the *javascript.options.wasm* option to true in about:config page first which is “disable WebAssembly for now” by default (don’t know why)…@Pants
I not sure how to read those benchmarks, other than bigger is better.
imgur.com/a/IlCUsxG
Something that doesn’t apply in these tests, where lower is terrible, yes, dear uBlock Origin, i’m looking at you.
https://avlab.pl/test-web-browser-extensions-protection-against-malicious-software
I’m not sure that’s a fair comparison – the other extensions seem to be running some bare-bones version of their respective antivirus engines, whereas uBO works on the basis of domain lists only (not even a blacklist of malicious software like Google Safe Browsing). If I understand correctly, uBO’s ‘protection’ should help you avoid going onto a number of known malicious websites, and is unable to analyse files/malware.
For me, WASM ended up being slightly slower than Trie 1st gen. Trie 2nd gen was also slower than 1st gen.
However, this was in an active, browser session with several tabs open though.
Same here. I linger to understand the WASM advantage in such experiences.
@TH: experiments ;-)
@Klaas Vaak, I’m curious indeed! Why are the WASM results slower but faster with ‘CanvasBlocker’ disabled. Security first but then between privacy and speed i admit far lower convictions as to which of the latter two should prevail. I don’t want to become an armored snail.
@TH: that was not my point, it was experience –> experiment :-)
@Klaas Vaak, experiments, not experiences … not as in my younger years when experimenting life throughout a few experiences (‘few’ because vanity discredits reality!). Thanks :=)
Back to my experiments, too old for experiences now!
I’ve tested again with Firefox’s ‘CanvasBlocker’ extension disabled and the difference on the WASM results is obvious : http://funkyimg.com/i/2NQf3.jpg
Both tests in same conditions, only testing page opened, cache/history cleaned.
I’ll have to dig into CanvasBlocker’s impact on WASM …
Good catch Tom!
With CanvasBlocker enabled I still saw higher benchmarks with WASM than with JS. After disabling CanvasBlocker in Nightly the WASM benchmark increased from 10,790 to 13,946. That’s kind of huge! ;)
***Firefox 65.0 on Windows Server 2008 R2 / 7 64-bit.
– Set-based x 1,614 ops/sec ±1.36% (62 runs sampled)
– Regex-based x 3,576 ops/sec ±0.31% (66 runs sampled)
– Trie-based (1st-gen) x 9,218 ops/sec ±0.23% (67 runs sampled)
– Trie-based JS (2nd-gen) x 7,917 ops/sec ±4.44% (44 runs sampled)
– Trie-based WASM (2nd-gen) x 13,946 ops/sec ±0.24% (66 runs sampled)
Done.
After disabling CanvasBlocker in FF I saw no change in the benchmark, both Nightly and FF have the same config in CanvasBlocker. That said, the WASM benchmark was higher than the JS benchmark, for me.
@Richard Allen, this said I won’t stop using ‘CanvasBlocker’ for the sake of gaining uBO velocity, but I am surprised on the impact of the extension on this uBObenchmark, and maybe is it only due to one or a few CanvasBlocker settings (mine are all optimal except the option ‘Misc > Block data URL pages’ unchecked because I use uBO , according to https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions).
I hope to get further information on this.
Interesting about canvas blocking. I don’t run Canvas Blocker, but I do have privacy.resistFingerprinting set to true, which also causes some form of canvas manipulation. This also causes the slower benchmark with WASM.
one person.
only _one_ person stands behind this (against the degenerated web). creepy. but gives hope. and he doesn’t even _want_ money for it. must be a convinced platonist. all those years: idealism. i can’t express my admiration often enough (but this will be the last time, because one day it will be enough), because here (as in my case) people not only talk, but act – actively and cooperation with the users.
on the other side: what he “benefited” from relying/trusting on others/forks can be seen on “ublock” (not to be confused with ublock origin (but that’s clear to everyone here anyway) :
adblock:
https://twitter.com/gorhill/status/1019975271443771392
https://www.ublock.org/announcement/
really horrible. i think so. set consequences. against such “manufacturers”. one still have the choice.
adblock plus:
https://twitter.com/gorhill/status/1065590045581680641
https://twitter.com/gorhill/status/1057752327292157952
https://twitter.com/gorhill/status/1037673095702691840
..
..
or – obviously: ghostery (burda) and other strange “blockers” especially in google store.
disconnect.me, ok – it’s already “in firefox” (so there is no reason for an extension-overkill by installing the disconnect.me addon if you use firefox).
and according to gorhill, the firefox content blocking + one of the two possible disconnect.me blacklists seems to have no negative effect in combination with ublock origin. but this is still untested (see following tweet).
but this extension-overkill also applies for other additional content blockers if ublock origin is used:
https://twitter.com/gorhill/status/1033706103782170625
and as for ghostery… so popular and so burda.
the rest: ok. too slow page loading & too much workload on my ancient system. + ugly. + overloaded. again – imho.
even the mwb – addon, which i praised earlier and whose development is progressing at a snail’s pace. no longer interested in it.
finally: thx for the further development of ublock origin & umatrix & for ghacks news.
Tbh, gorhill does cooperate quite a bit with the AdGuard team – I consider theirs an almost-equally good product.
uBO is living proof that something is wrong with the way the market works nowadays, as all other content blockers need to add problems to offer an artificial solution.
I had manually updated uBlock Origin to 17.4 this morning via the uninstall 17.0 – go to Chrome webstore – install 17.4 method as I was not sure if the method described in September would work here. All seems good.
Using Chrome and uBO 1.17.4 and the referenced benchmark got me
Benchmarking, the higher ops/sec the better.
Chrome 71.0.3578.75 on Windows 10 64-bit.
Test 100 needles against 16 dictionaries of hostnames
– Set-based x 2,162 ops/sec ±1.47% (60 runs sampled)
– Regex-based x 2,679 ops/sec ±2.77% (59 runs sampled)
– Trie-based (1st-gen) x 5,152 ops/sec ±1.78% (59 runs sampled)
– Trie-based JS (2nd-gen) x 4,686 ops/sec ±3.19% (28 runs sampled)
– Trie-based WASM (2nd-gen) x 6,374 ops/sec ±2.74% (36 runs sampled)
Done.
Benchmarking, the higher ops/sec the better.
Firefox 63.0 on Windows Server 2008 R2 / 7 64-bit.
Test 100 needles against 16 dictionaries of hostnames
– Set-based x 1,689 ops/sec ±1.11% (13 runs sampled)
– Regex-based x 3,937 ops/sec ±0.54% (24 runs sampled)
– Trie-based (1st-gen) x 9,176 ops/sec ±0.22% (50 runs sampled)
– Trie-based JS (2nd-gen) x 7,126 ops/sec ±0.23% (65 runs sampled)
– Trie-based WASM (2nd-gen) x 7,421 ops/sec ±0.66% (41 runs sampled)
Done.
So my results show higher higher ops/sec, but less runs??
Nice!
FYI : if you’re running Firefox’s ‘Decentraleyes’ extension with the option ‘Block requests from missing resources’ activated, you’ll have to add ‘cdn.jsdelivr.net’ in the extension’s ‘Exclude domains from inspections’ list (cdn.jsdelivr.net calls cdn.jsdelivr.net which needs its cdn version) otherwise the benchmark won’t start.
And here are the results from Helsinki… from Paris, sorry :
Benchmarking, the higher ops/sec the better.
Firefox 63.0 on Windows Server 2008 R2 / 7 64-bit.
Test 100 needles against 16 dictionaries of hostnames
– Set-based x 1,318 ops/sec ±1.89% (11 runs sampled)
– Regex-based x 2,362 ops/sec ±0.14% (16 runs sampled)
– Trie-based (1st-gen) x 7,135 ops/sec ±0.21% (66 runs sampled)
– Trie-based JS (2nd-gen) x 5,308 ops/sec ±0.20% (31 runs sampled)
– Trie-based WASM (2nd-gen) x 6,143 ops/sec ±0.21% (65 runs sampled)
Done.
Device used is getting old :=)
Is the use of WebAssembly required? In other words, will it work for people who don’t allow WebAssembly code to run in their browsers?
Personally, I use (pre-Quantum) NoScript, as I’m concerned about code running in my browser, not ads as such. However, the side-effect is that it blocks ads.
I found the answer to my question — according to the developer, the use of WASM is and will remain optional.
Thanks Martin. For some time now I’ve been very intrigued with what webassembly will bring to browser performance and of course Mr. Hill would put it to good use! Here’s a link for one of many articles I’ve seen on webassembly for those interested in reading up on it:
“https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/”
I saw an improvement in the WASM benchmark with FF and an even bigger improvement in Nighty. I’ve been using Nightly a lot the last week or so because it’s been working so well and this kind of proves it wasn’t entirely my imagination. ;)
https://i.postimg.cc/ZngmP1kN/FF-Nightly-v65-u-BO.png
https://i.postimg.cc/RCbvzn30/FF-v63-u-BO.png
With Waterfox in my “Test” profile I couldn’t get the webext version of uBO to do the WASM benchmark, and yes, WASM is enabled. My “default” WF profile uses the legacy version and I updated it to the webext and it wouldn’t run the WASM portion of the benchmark either. The JS benchmark was better in uBO Legacy than it is in the Webext.
https://i.postimg.cc/L569HtSy/WF-Test-Profile-u-BO-1-17-4.png
https://i.postimg.cc/qMqJSxjq/WF-u-BO-v-1-16-4-5.png
Lately, for me, Chrome Dev has absolutely been killing it with “performance”. I don’t know why but my install of Chrome Stable and Chrome Dev both show WASM working in the benchmark with WASM having much better numbers compared to JS. I’m using around 40 flags and maybe a half dozen command line switches so I’m not sure yet what’s going on. Last week I noticed a major improvement in memory use with Chrome Dev, it was using less memory than what I saw in FF, both had the same 5 tabs open. When Google removed “trivial” portions of URLs I had uninstalled Chrome Stable, after seeing the memory use in Dev I had to reinstall Stable to see what it was doing. In Stable and Dev I saw about 200MB less memory being used (couple days ago) with my flags enabled versus without the flags. Without all of those flags that I use, both Stable and Dev still use more memory than FF. I don’t remember the last time Chrome used less memory than FF, not on my hardware and all of my browser installs have had multiple clean installs over the years, my oldest install right now is from when I did a clean install to FF v57, everything else is a newer clean install.
https://i.postimg.cc/DwMdK6rz/Chrome-Dev-u-BO.png
https://i.postimg.cc/2644hfPq/Chrome-Stable-u-BO.png
Out of curiosity, which flags do you use?
I took the lazy way out. Sorry! There are a few differences from Stable to Dev.
Chrome Dev:
“C:\Program Files (x86)\Google\Chrome Dev\Application\chrome.exe” –process-per-site –disk-cache-size=104857600 –cipher-suite-blacklist=0x009C,0x009d,0x002f,0x0035,0x000a –ssl-version-min=tls1.2 –enable-native-gpu-memory-buffers –flag-switches-begin –autoplay-policy=document-user-activation-required –no-pings –blink-settings=disallowFetchForDocWrittenScriptsInMainFrame=true –enable-fast-unload –enable-gpu-rasterization –history-entry-requires-user-gesture –disable-quic –enable-zero-copy –ignore-gpu-blacklist –load-media-router-component-extension=0 –num-raster-threads=4 –reduced-referrer-granularity –disable-site-isolation-trials –enable-smooth-scrolling –v8-cache-options=code –enable-features=BlockTabUnders,ExpensiveBackgroundTimerThrottling,FontCacheScaling,FramebustingNeedsSameOriginOrUserGesture,InfiniteSessionRestore,NewAudioRenderingMixingStrategy,OverlayScrollbar,OverlayScrollbarFlashAfterAnyScrollUpdate,OverlayScrollbarFlashWhenMouseEnter,PageAlmostIdle,ParallelDownloading,ProactiveTabFreezeAndDiscard,ScrollAnchorSerialization,SimplifyHttpsIndicator,stop-non-timers-in-background –disable-features=HappinessTrackingSurveysForDesktop,LazyFrameLoading,LazyImageLoading,MarkHttpAs,NetworkService,NoStatePrefetch,OmniboxSpeculativeServiceWorkerStartOnQueryInput,OmniboxUIExperimentHideSteadyStateUrlPathQueryAndRef,OmniboxUIExperimentHideSteadyStateUrlScheme,OmniboxUIExperimentHideSteadyStateUrlTrivialSubdomains,QueryInOmnibox,SystemWebApps,ZeroSuggestRedirectToChrome –flag-switches-end
Chrome Stable:
“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –process-per-site –disk-cache-size=104857600 –cipher-suite-blacklist=0x009C,0x009d,0x002f,0x0035,0x000a –ssl-version-min=tls1.1 –enable-native-gpu-memory-buffers –flag-switches-begin –autoplay-policy=document-user-activation-required –no-pings –blink-settings=disallowFetchForDocWrittenScriptsInMainFrame=true –enable-fast-unload –enable-gpu-rasterization –history-entry-requires-user-gesture –disable-quic –enable-tab-audio-muting –enable-zero-copy –ignore-gpu-blacklist –load-media-router-component-extension=0 –num-raster-threads=4 –reduced-referrer-granularity –disable-site-isolation-trials –enable-smooth-scrolling –v8-cache-options=code –enable-features=AutomaticTabDiscarding,BackgroundVideoTrackOptimization,BlockTabUnders,ExpensiveBackgroundTimerThrottling,FontCacheScaling,FramebustingNeedsSameOriginOrUserGesture,OverlayScrollbar,OverlayScrollbarFlashAfterAnyScrollUpdate,OverlayScrollbarFlashWhenMouseEnter,PageAlmostIdle,ParallelDownloading,ProactiveTabFreezeAndDiscard,SimplifyHttpsIndicator,SoundContentSetting,SpeculativePreconnect,ZeroSuggestRedirectToChrome,stop-non-timers-in-background –disable-features=HappinessTrackingSurveysForDesktop,LazyFrameLoading,LazyImageLoading,MarkHttpAs,NetworkService,NoStatePrefetch,OmniboxSpeculativeServiceWorkerStartOnQueryInput,OmniboxUIExperimentHideSteadyStateUrlSchemeAndSubdomains,QueryInOmnibox –flag-switches-end
Well Hell, that looks ugly. LoL
https://i.postimg.cc/C185Lz73/Chrome-Dev.png
https://i.postimg.cc/Y0fSYZJ8/Chrome-Stable.png
I have a Chrome Flags file saved in Dropbox I finally updated. I’m not recommending any of them be used without knowing first what they are doing. The flags are what I’m using currently on my hardware with my bandwidth (120Mbps down – 6Mbps up). My desktop is using Win7 x64, a 4 core processor, 16GB RAM and discreet graphics.
Some flags can cause problems depending on the Chrome version used and updates. Zero-copy rasterizer, 3D software rasterizer, MSAA sample count and Out of process rasterization can cause intermittent problems, for me. There are flags like lazy image loading and lazy frame loading that I don’t use which might help those with older hardware or limited bandwidth. I have no need for them and I don’t want to see elements rendering in the viewport more than they already do now by default but that doesn’t mean those flags won’t be useful for others. And then there are flags like Auto Tab Discarding that probably are not doing anything for me because of how much memory I have. Point is, there are a lot of considerations to take into account when using flags. The flags I use have always been a work in progress!!!
The “Local State” file in the profile is where the flag settings are stored. The flags can be reset to their default and then restored by replacing the Local State file if it was saved. With Chrome closed you can drag the file out of the profile folder onto the desktop and the file will be recreated at Chrome startup, without any flags. Which is what I do when testing with and without flags enabled in Chrome and Vivaldi. Also, the preference “Continue running background apps when Google Chrome is closed” is stored in the Local State file.
Chrome Flags:
https://www.dropbox.com/s/espv5j2raqtyyt4/Chrome%20Flags?dl=0
uBlock Origin is a great browser extension. It’s a pity though that it is no longer under active development for Pale Moon (etc.).
On ESR52 I have uBlock Origin 1.16.4.5
@Yuliya. That’s the legacy version have on Pale Moon too. The current uBlock Origin version is 1.17.4 (released Dec 1, 2018).
The end of uBlock Origin as we know it, or, the end of adblocking in Chromium based browsers as we know it?
https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-452843669