Mirrors/uBlock
1
0
Fork 0
mirror of https://github.com/gorhill/uBlock.git synced 2024-07-08 12:57:57 +02:00
Code Issues Releases Wiki Activity

Grammar / Rewording fixes

q1800 2022-04-12 19:34:05 -05:00
parent 492d745272
commit 91b9ff0638
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Myth:-uBlock-consumes-over-80MB.md

@ -5,18 +5,18 @@ I've seen a couple of instances of people claiming uBlock Origin (uBO) is not as
When uBO launches, it loads all selected filter lists, parses the content, eliminates duplicates, then instantiates the filters using efficient internal representation. This parsing of the filter lists requires a good amount of temporary memory.
So if you look at the task manager **right after** uBO has loaded and parsed the filter lists, you will still see uBO's memory footprint as a result of loading all the filter lists. Still, at this point all this temporary memory has been relinquished to the browser, but the browser hasn't yet collected the freed memory to make it available for reuse.
So if you look at the task manager **right after** uBO has loaded and parsed the filter lists, you will still see uBO's memory footprint due to the loading of all the filter lists. Still, at this point, all this temporary memory has been relinquished to the browser, but the browser hasn't yet collected the freed memory to make it available for reuse.
If the browser is idle enough, before one minute has elapsed<sup>[1]</sup>, the browser should be able to [garbage collect](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) the temporary memory which was freed by uBO after it finished loading and parsing the filter lists:
![uBO's memory footprint](https://raw.githubusercontent.com/gorhill/uBlock/master/doc/img/mem-footprint-at-launch-time.png)
The top image shows the memory footprint of uBO right after launch (Chrome 64-bit) (expect similar memory footprint each time the filter lists have to be reloaded). The image at the bottom shows the memory footprint of uBO before one minute has elapsed while the browser is idle.
The top image shows the memory footprint of uBO right after launch (Chrome 64-bit) (expect a similar memory footprint each time the filter lists get reloaded). The image at the bottom shows the memory footprint of uBO before one minute has elapsed while the browser is idle.
Note that uBO's baseline memory footprint won't change that much afterwards. It will likely settle a few MB above the memory footprint reached after garbage collection has occurred, whenever the garbage collector is permitted to do its job.
Note that uBO's baseline memory footprint won't change that much afterward. It will likely settle a few MB above the memory footprint reached after garbage collection has occurred, whenever the garbage collector is permitted to do its job.
When reloading all filters (after changing selection of filter lists, for example), I notice uBO's baseline memory footprint edges higher each time. I entered [an issue](https://github.com/gorhill/uBlock/issues/22) to be reminded to investigate whether anything can be done for this. Currently I think this is simply caused by cumulative memory fragmentation and there might not be anything which can be done. Typically I expect users will select a set of lists and stick to that afterward, so this would make this particular issue irrelevant.
When reloading all filters (after changing the selection of filter lists, for example), I notice uBO's baseline memory footprint edges higher each time. I entered [an issue](https://github.com/gorhill/uBlock/issues/22) to remind myself to investigate whether there is anything to be done for this. Currently, I think the cause is cumulative memory fragmentation, and there might not be anything to be done. Typically I expect users will select a set of lists and stick to that afterward, so this would make this particular issue irrelevant.
***
[1] In latest release of Chromium (40+) I have notice that the garbage collector can be rather "lazy", i.e. meaning sometimes it takes a while before freed memory is garbage collected. It's why that when surveying memory usage it is important to **force** a garbage collection cycle using the dev console of the extension itself.
[1] In the latest release of Chromium (40+), I have noticed that the garbage collector can be "lazy" (meaning sometimes it takes a while before freed memory is garbage collected). When surveying memory usage, it is essential to **force** a garbage collection cycle using the dev console of the extension itself.