µBlock vs. ABP: efficiency compared
Here is a quick illustrated comparison of efficiency using various angles. Each extension were tested alone, as the only extension present. Benchmarking was performed with Chromium on Linux Mint 64-bit.
- Own memory footprint
- Added CPU overhead to each net request
- Added memory footprint to web pages
- Added CPU overhead to web pages
These screenshots show the memory footprint of ABP and µBlock after they have gone through this rather demanding benchmark. Once the benchmark was completed, I forced the browser to garbage collect the memory in each extension by clicking the trash icon (in dev console) a couple of times -- this is an important step, or else the shown memory footprint is not too reliable.
Both extensions had EasyList, EasyPrivacy, Peter Lowe's Ad Server list, and malware protection (there are more filters in µBlock for this last one).
ABP and µBlock need to evaluate the URL of each net request against their dictionary of filters, and eventually tell the waiting browser whether the request should be cancelled or not. Since the browser is waiting for an answer, this is a time critical part and determining whether the request should be allowed or not must be done as fast as possible.
Below are the average time it takes for each extension to handle a net request in their respective chrome.webRequest.onBeforeRequest handler, using the same benchmark.
ABP > onBeforeRequest: 0.286 ms (19448 samples)
ABP > onBeforeRequest: 0.286 ms (19697 samples)
ABP > onBeforeRequest: 0.286 ms (19890 samples)
ABP > onBeforeRequest: 0.285 ms (20157 samples)
ABP > onBeforeRequest: 0.284 ms (20675 samples)
ABP > onBeforeRequest: 0.284 ms (20790 samples)
ABP > onBeforeRequest: 0.284 ms (20956 samples)
ABP > onBeforeRequest: 0.284 ms (21112 samples)
ABP > onBeforeRequest: 0.283 ms (21279 samples)
ABP > onBeforeRequest: 0.283 ms (21472 samples)
µBlock > onBeforeRequest: 0.173 ms (18913 samples)
µBlock > onBeforeRequest: 0.172 ms (19177 samples)
µBlock > onBeforeRequest: 0.172 ms (19354 samples)
µBlock > onBeforeRequest: 0.172 ms (19681 samples)
µBlock > onBeforeRequest: 0.171 ms (20139 samples)
µBlock > onBeforeRequest: 0.171 ms (20311 samples)
µBlock > onBeforeRequest: 0.171 ms (20461 samples)
µBlock > onBeforeRequest: 0.171 ms (20610 samples)
µBlock > onBeforeRequest: 0.171 ms (20756 samples)
µBlock > onBeforeRequest: 0.171 ms (20933 samples)
Note that the results above are the tail end of running the complete benchmark (60 front pages of high traffic web sites, repeated 3 times).
Also noteworthy, ABP uses a cache mechanism to possibly avoid having to test a URL by trying to reuse a prior result for that same URL, which would cause ABP timing to be quite low (at the expense of memory footprint). It's unclear to me how much this mechanism kicked in with the current benchmark. µBlock doesn't use such mechanism, so whether a web page is visited repeatedly or not doesn't influence timing.
Extensions have their own memory footprint, but they also cause increased memory footprint in web pages. Below you can see the added memory footprint in a very simple web page, Hacker News. First screenshot is when no extension at all is used, so consider it as the reference memory footprint for this web page, other screenshots show the increased memory footprint caused by each extension. The browser was left on idle after loading the page in order to allow the garbage collector to kick in.
No extension:
Adblock Plus:
µBlock:
Now keep in mind this is the added footprint for a very simple web page which has no embedded frames. You can multiply the added footprint on the main page by the number of frames embedded on a page, so page with frames can end up consuming a lot more memory than they would have otherwise. For instance, a very simple web page with a couple of iframe in it, The Acid3 Test:
Added memory footprint: Left = no extension. Middle = Adblock Plus. Right = µBlock.
A good stress test which further demonstrate this is the infamous vim test.
Above picture gives an overview of how much more memory Adblock Plus consumes over µBlock. It represents the extra memory ABP consumes relative to µBlock -- so essentially µBlock is the horizontal axis. If memory consumption of ABP and µBlock were exactly the same, there would be no graph. The reference benchmark was used, which consists of visiting 60 front pages of high traffic web sites.
The vertical axis represents MB. The horizontal axis is time in seconds, and the data was tediously extracted from this video (consider the video to be the raw data -- here is the spreadsheet so people can double check in doubt).
The blue area represents how much more ABP itself consumes more memory than µBlock. The orange area represents how much more ABP causes the web pages themselves to consume more memory. ABP systematically causes web pages to consume more memory, and often quite a lot, north of 100 MB for some sites. This kind of added short term memory overhead is not cheap, as it also means the CPU is working harder.
This is the benchmarks comparing CPU usage in the background page when loading si.com ten times. Each page load was triggered after the previous page load completed.
Top: Adblock Plus 1.8.3. Bottom: µBlock 0.5.1.0.
I did measure CPU usage for content scripts (above is background page), but given the web page used for the benchmark is quite a bloated one, the useful figures were drawn in a see of noise. But the fact that ABP inserts 14,000+ CSS rules caused the CPU to used be much more than µBlock (3 to 1 ratio) when comparing content script CPU usage (above is background page CPU usage).
Also, the amount of work µBlock does in its content scripts is proportional to the complexity of a web page. So given µBlock did much better than ABP in its content script for such a bloated web site means it has the right approach to implementing cosmetic filters.