-
Notifications
You must be signed in to change notification settings - Fork 77
Memory footprint: what happens inside uBlock after installation
q1800 edited this page Apr 2, 2022
·
7 revisions
- uBlock Origin (uBO) will load the default selection of filter lists:
- This causes short-term memory churning (loading/parsing/sorting/storing); short-term memory will be garbage-collected eventually
- All this short-term memory churning causes uBO's baseline memory footprint to grow further
- A few minutes later, uBO will look whether one or more filter lists needs to be updated
- If one or more filter lists need to be updated, uBO will launch a background task which will fetch an updated version of whatever filter list is obsolete
- Once all filter lists are brought up to date, uBO will flush from memory all filters and reload them with the latest version
- This will cause another round of short-term memory churning; short-term memory will be garbage-collected eventually
- Again, all this short-term memory churning causes uBO's baseline memory footprint to grow further
- You can disable auto-update if you want, but it is optimal to let uBO take care of this, i.e. manually forcing an update is sub-optimal
-
A few minutes later, assuming no change in selection of filter lists, or change in the content of selected filter lists, uBO will make a selfie
- A selfie allows uBO to skip the parsing/sorting of data next time it loads
- Generating the selfie also causes short-term memory churning; short-term memory will be garbage-collected eventually
- Again, this short-term memory churning causes uBO's baseline memory footprint to grow further
- Any change in the selection of filter lists, or change in the content of selected filter lists will invalidate uBO's selfie
- Even after the growth in memory baseline, uBO's own memory footprint is still quite a bit smaller than that of Adblock Plus (ABP) -- once the garbage collector does its job
- uBO's much smaller contributed memory footprint to web pages is much smaller than that of ABP
- The contributed footprint to web pages is part of the memory footprint of the web pages themselves
- As opposed to an extension's own memory footprint, visible using Chromium's "Task Manager", the contributed memory footprint to web pages cannot be easily seen by users
- Though this measure is not readily visible, it's where you get the biggest bang for the buck with uBO relative to ABP -- because uBO does not inject thousands of CSS rules into pages and embedded frames (unlike ABP)
Once you have reached the point where there is a valid uBO selfie, uBO will run the most efficiently.
The next time you launch uBO with a valid selfie, the load time will be a fraction of that when no selfie is available [1]. uBO's baseline memory footprint will be smaller than when uBO launches with no selfie.
So my point is that uBO will perform at its best efficiency if you give it time to optimize itself after installation: In subsequent launches, uBO will perform more efficiently than what you may have observed immediately after installation.
[1] See https://www.youtube.com/watch?v=BpypOeK10N8
Also, if you want to look at memory figures, in addition to the above notes regarding garbage collection, keep in mind:
- The Chromium bug causes systematic memory leaks when opening an extension popup UI.
- Currently opened extension options page(s) contribute to increasing the extension's memory use
- Sometimes, a browser's garbage collector ("GC") is lazier than others; therefore, it may take longer to kick in.
- In my benchmarks, it has happened that I had to force a GC cycle using dev tools.
- Notes: The above is especially true for a Chromium-based browser. However, with the early preview of the Firefox version, the memory churning referred to above seems to result in much smaller memory peak usage.
- Related: "Notes on memory benchmarks, selfies"
- Beware: "Popup UI of extensions causes systematic memory leaks"
- Wiki home
- About the Wiki documentation
- Permissions
- Privacy policy
- Info:
- The toolbar icon
- The popup user interface
- The context menu
-
Dashboard
- Settings pane
- Filter lists pane
- My filters pane
- My rules pane
- Trusted sites pane
- Keyboard shortcuts
- The logger
- Element picker
- Element zapper
-
Blocking mode
- Very easy mode
- Easy mode (default)
- Medium mode (optimal for advanced users)
- Hard mode
- Nightmare mode
- Strict blocking
- Few words about re-design of uBO's user interface
- Reference answers to various topics seen in the wild
- Overview of uBlock's network filtering engine
- uBlock's blocking and protection effectiveness:
- uBlock's resource usage and efficiency:
- Memory footprint: what happens inside uBlock after installation
- uBlock vs. ABP: efficiency compared
- Counterpoint: Who cares about efficiency, I have 8 GB RAM and|or a quad core CPU
- Debunking "uBlock Origin is less efficient than Adguard" claims
- Myth: uBlock consumes over 80MB
- Myth: uBlock is just slightly less resource intensive than Adblock Plus
- Myth: uBlock consumes several or several dozen GB of RAM
- Various videos showing side by side comparison of the load speed of complex sites
- Own memory usage: benchmarks over time
- Contributed memory usage: benchmarks over time
- Can uBO crash a browser?
- Tools, tests
- Deploying uBlock Origin
- Proposal for integration/unit testing
- uBlock Origin Core (Node.js):
- Troubleshooting:
- Good external guides:
- Scientific papers