prehistoric-systems/uBlock
1
0
Fork 0
mirror of https://github.com/gorhill/uBlock.git synced 2026-03-11 09:04:36 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Updated Notes on memory benchmarks, selfies (markdown)

Raymond Hill 2016-06-06 10:41:23 -04:00
parent 687928264a
commit f002fd2f0c
2 changed files with 51 additions and 42 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

42
Notes on memory benchmarks, selfies.md

@ -1,42 +0,0 @@
µ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](https://github.com/gorhill/uBlock/wiki/Myth:-%C2%B5Block-consumes-over-80MB). 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](http://en.wikipedia.org/wiki/Fragmentation_(computing)#External_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):<br>
![Without selfie](https://raw.githubusercontent.com/gorhill/uBlock/master/doc/img/ublock-vs-abp-memory-201409-a.png)
With a selfie available:<br>
![With selfie](https://raw.githubusercontent.com/gorhill/uBlock/master/doc/img/ublock-vs-abp-memory-201409-b.png)
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](https://github.com/gorhill/uBlock/wiki/Reference-benchmark) completed, and closing all web pages except the _Extensions_ page.
### Reminder
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](https://github.com/gorhill/uBlock/wiki/%C2%B5Block-vs.-ABP:-efficiency-compared#added-memory-footprint-to-web-pages) relative to µBlock's contributed memory footprint can easily **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.

51
Notes-on-memory-benchmarks,-selfies.md Normal file

@ -0,0 +1,51 @@
uBlock Origin ("uBO") 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](https://github.com/gorhill/uBlock/wiki/Myth:-%C2%B5Block-consumes-over-80MB). 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 uBO 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 uBO 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](http://en.wikipedia.org/wiki/Fragmentation_(computing)#External_fragmentation) is possibly a factor.
Memory-churning operations lead to a permanently higher memory baseline for uBO, 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 uBO 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 uBO. Here are operations which causes all the filters to be reloaded:
- Launching or restarting uBO (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+, uBO 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 uBO will become very efficient CPU- and memory-wise -- as all the downloading/parsing of filters from raw text files will be completely bypassed, causing uBO 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 uBO'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):<br>
![Without selfie](https://raw.githubusercontent.com/gorhill/uBlock/master/doc/img/ublock-vs-abp-memory-201409-a.png)
With a selfie available:<br>
![With selfie](https://raw.githubusercontent.com/gorhill/uBlock/master/doc/img/ublock-vs-abp-memory-201409-b.png)
Benchmark details:
- Google Chrome 37 64-bit on Linux Mint
- Plug-ins set to _"Click to play"_
- Third-party cookies disabled
- uBO: default filter lists
- ABP: _EasyList_, _EasyPrivacy_, _Malware Domains_. _"Acceptable ads"_ disabled
- Screenshots taken at least 15 minutes after [reference benchmark](https://github.com/gorhill/uBlock/wiki/Reference-benchmark) completed, and closing all web pages except the _Extensions_ page.
### Reminder
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](https://github.com/gorhill/uBlock/wiki/%C2%B5Block-vs.-ABP:-efficiency-compared#added-memory-footprint-to-web-pages) relative to µBlock's contributed memory footprint can easily **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.
### Addendum
If you benchmark memory usage, you also need to keep in mind the following. The memory footprint of uBO proper will be higher if ...
- uBO's dashboard is opened;
- uBO's logger is opened;
- You looked up from which filter list(s) a filter originate in uBO's logger;
- You did not let your browser's garbage collector do its job after a memory intensive operation.