Notes on memory benchmarks, selfies
µBlock is quite memory efficient compared to most other blockers. However, users will often report that this is not the case, or not as impressive as "advertised" by the official documentation.
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.
Memory-churning operations lead to a permanently 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 cause µBlock to go through memory-churning before looking at the memory figures, even after letting the browser's garbage collector do its job.
Memory-churning of course applies to all extensions. The difference with other blockers might be what operations lead to memory-churning. Reloading all the filters is the most severe memory-churning operation in µBlock. 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 (this may be done automatically if Auto-update is enabled).
Additionally, with version 0.6+, µBlock is able to 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 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, causing µBlock to be fully loaded and ready in a fraction of the time it takes when no good selfie is available.
The time at which a selfie is created is at µBlock's discretion. Currently, this will happen some minutes after the filter lists have 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, and the filter lists themselves may have grown since then (I have to check). 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 (one was created during the benchmark):
With a selfie available:
Benchmark details:
- Google Chrome 37 64-bit on Linux Mint
- Plug-ins set to "Click to play"
- Third-party cookies disabled
- µBlock: default filter lists
- ABP: EasyList, EasyPrivacy, Malware Domains. "Acceptable ads" disabled
- Screenshots taken at least 15 minutes after reference benchmark completed, and closing all web pages except the Extensions page.
Remember, what is covered above is what I call the extension's own memory. The worst though is the contributed memory footprint by Adblock Plus for web pages. The sum of all contributed memory footprint by ABP to all opened web pages relative to µBlock's contributed memory footprint dwarf the difference shown above, due to the fact that ABP will inject 14,000+ CSS rules in every web page, and every iframe of every web page, and this is when using EasyList only.