Skip to content

Notes on memory benchmarks, selfies

Jump to bottom Edit New page
gorhill edited this page Sep 9, 2014 · 33 revisions

µBlock is quite memory efficient compared to most other blockers. However, users will often report that this is not the case. I already wrote about this here. I will add more details here, as there is more than just garbage collection to factor in.

When I run my benchmarks, the methodology used is to reproduce what I believe is the most common scenario: a user launches his/her browser with µBlock already fully configured to his/her liking, without further changes to the selection of filter lists. The launch-and-forget scenario. I also benchmark this way for all other blockers.

However there are specific operations which will cause µBlock to churn through lot of short-term memory (let's call this "memory-churning"), and although all that short-term memory is freed by µBlock once the specific operation is completed, not all that freed memory will be garbage-collected by the browser for whatever reasons. Memory fragmentation is possibly a factor. This causes an higher memory baseline for µBlock, as can be seen in the browser's Task Manager.

So in essence you won't obtain the same memory figures which I used in my published benchmarks if you caused µBlock to go through memory-churning before looking at the memory figures.

Reloading all the filters is quite a memory-churning operation. Here are operations which causes all the filters to be reloaded:

  • Launching or restarting µBlock (obviously).
  • Changing the selection of filter lists.
  • Adding removing custom filters.
  • Updating the filter lists.

Additionally, with version 0.6+, µBlock will create a selfie to improve its load time next time the browser is launched, and creating a selfie is also a memory-churning operation. However for this one particular operation, once the selfie is created, the reward is that subsequent re-launch of µBlock will become very efficient CPU- and memory-wise -- as all the downloading/parsing of filters from raw text files will be completely bypassed.

The time at which a selfie is created is at µBlock's discretion. Currently, this will happen some minutes after the filter lists has been loaded, so as to avoid launching memory-churning selfie creation operations before there is a good likelihood the user is done tampering with his selection of filters.

Take note that all the benchmarks appearing on the main page are quite dated at this point, a lot of code has been added or changed in µBlock. So for version 0.6. I ran the reference benchmark to find out where µBlock stands memory efficiency-wise -- along with ABP 1.8.3 for comparison.

Without a selfie available:
Without selfie

With a selfie available:
With selfie

Benchmark details:

  • Google Chrome 37 64-bit on Linux Mint.
  • µBlock: default filter lists
  • ABP: EasyList, EasyPrivacy, Malware Domains. "Acceptable ads" disabled
  • Screenshots taken at least 15 minutes after running reference benchmark and closing all web pages except the Extensions page.

uBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean.

Clone this wiki locally