mirror of
https://github.com/gorhill/uBlock.git
synced 2024-10-06 09:37:12 +02:00
Fixed typographical errors, spelling mistakes, punctuation inconsistencies, and grammer issues; no changes made to author's message
parent
c5ba4f0df8
commit
4ea9654398
@ -1,35 +1,35 @@
|
|||||||
1. uBlock will load the default selection of filter lists:
|
1. uBlock will load the default selection of filter lists:
|
||||||
- This causes short-term memory churning (loading/parsing/sorting/storing), which short-term memory will be garbage-collected eventually
|
- 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 uBlock's baseline memory footprint to grow further
|
- All this short-term memory churning causes uBlock's baseline memory footprint to grow further
|
||||||
1. **A few minutes later**, uBlock will look whether one or more filter lists need to be updated
|
1. **A few minutes later**, uBlock will look whether one or more filter lists needs to be updated
|
||||||
1. If one or more filter lists need to be updated, uBlock will launch a background task which will fetch an updated version of whatever filter list is deemed obsolete
|
1. If one or more filter lists need to be updated, uBlock will launch a background task which will fetch an updated version of whatever filter list is obsolete
|
||||||
1. Once all filter lists are brought up to date, uBlock will flush from memory all filters and reload with the latest version
|
1. Once all filter lists are brought up to date, uBlock will flush from memory all filters and reload them with the latest version
|
||||||
- This will causes another round of short-term memory churning, which short-term memory will be garbage-collected eventually
|
- 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 uBlock's baseline memory footprint to grow further
|
- Again, all this short term memory churning causes uBlock's baseline memory footprint to grow further
|
||||||
- You can disable auto-update if you want, but it is optimal to let µBlock take care of this, i.e. manually forcing an update is sub-optimal
|
- You can disable auto-update if you want, but it is optimal to let uBlock take care of this, i.e. manually forcing an update is sub-optimal
|
||||||
1. **A few minutes later**, assuming no change in selection of filter lists, or change in the content of selected filter lists, uBlock will make a selfie
|
1. **A few minutes later**, assuming no change in selection of filter lists, or change in the content of selected filter lists, uBlock will make a selfie
|
||||||
- A selfie allows µBlock to skip the parsing/sorting of data next time it loads
|
- A selfie allows uBlock to skip the parsing/sorting of data next time it loads
|
||||||
- Generating the selfie also causes short-term memory churning, which short-term memory will be garbage-collected eventually
|
- Generating the selfie also causes short-term memory churning; short-term memory will be garbage-collected eventually
|
||||||
- Again, this short term memory churning causes uBlock's baseline memory footprint to grow further
|
- Again, this short-term memory churning causes uBlock'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 uBlock's selfie
|
- Any change in the selection of filter lists, or change in the content of selected filter lists will invalidate uBlock's selfie
|
||||||
1. Even after the growth in memory baseline, uBlock's _own memory_ footprint is still quite smaller than that of Adblock Plus -- once the garbage collector does its job.
|
1. Even after the growth in memory baseline, uBlock's _own memory_ footprint is still quite a bit smaller than that of Adblock Plus (ABP) -- once the garbage collector does its job
|
||||||
1. uBlock's much smaller _contributed memory_ footprint to web pages is much smaller than that of ABP
|
1. uBlock'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
|
- 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
|
- 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 µBlock relative to ABP -- because uBlock **does not** inject thousands of CSS rules into pages and embedded frames.
|
- Though this measure is not readily visible, it's where you get the biggest bang for the buck with uBlock relative to ABP -- because uBlock **does not** inject thousands of CSS rules into pages and embedded frames
|
||||||
|
|
||||||
Now if you have reached the point where there is a valid uBlock selfie, this is when µBlock will run the most efficiently.
|
Once you have reached the point where there is a valid uBlock selfie, µBlock will run the most efficiently.
|
||||||
|
|
||||||
The next time you launch uBlock and there is a valid selfie, the load time will be a fraction of the load time when no selfie is available <sup>[1]</sup>, and uBlock's baseline memory footprint will be smaller than when uBlock launches without a selfie available.
|
The next time you launch uBlock and there is a valid selfie, the load time will be a fraction of the load time when no selfie is available <sup>[1]</sup>, and uBlock's baseline memory footprint will be smaller than when uBlock launches without a selfie available.
|
||||||
|
|
||||||
So my point is that uBlock will perform best efficiency wise if you leave it time to optimize itself after installation: In subsequent launches, uBlock will perform more efficiently than what you may have observed right after you installed it.
|
So my point is that uBlock will perform at best efficiency if you give it time to optimize itself after installation: In subsequent launches, uBlock will perform more efficiently than what you may have observed immediately after you installed it.
|
||||||
|
|
||||||
<sub>[1] See <https://www.youtube.com/watch?v=BpypOeK10N8></sub>
|
<sub>[1] See <https://www.youtube.com/watch?v=BpypOeK10N8></sub>
|
||||||
***
|
***
|
||||||
|
|
||||||
Also, if you want to look at memory figures, aside the above notes regarding garbage collection, keep in mind:
|
Also, if you want to look at memory figures, in addition to the above notes regarding garbage collection, keep in mind:
|
||||||
|
|
||||||
- The [Chromium bug](https://code.google.com/p/chromium/issues/detail?id=441500) which causes systemetically a memory leak when opening an extension popup UI.
|
- The [Chromium bug](https://code.google.com/p/chromium/issues/detail?id=441500) which causes systematically a memory leak when opening an extension popup UI.
|
||||||
- Currently opened extension option page(s) contribute to increase the extension's memory use
|
- Currently opened extension option page(s) contribute to increase the extension's memory use
|
||||||
- Sometimes a browser's garbage collector ("GC") is lazier than others, i.e. it may takes longer to kick in.
|
- Sometimes a browser's garbage collector ("GC") is lazier than others, i.e. it may takes longer to kick in.
|
||||||
- In my benchmarks, it has happened I had to force a GC cycle using dev tools.
|
- In my benchmarks, it has happened I had to force a GC cycle using dev tools.
|
||||||
|
Loading…
Reference in New Issue
Block a user