Disabling cosmetic filtering (aka ABP's "element hiding") is a big contributor to memory and CPU footprint, and specifically disabling cosmetic filtering (from the 3rd-party filters tab) feature is an easy way to decrease significantly memory and CPU footprint, which may come in handy for users browsing on less poweful devices.
Not sure how often cosmetic filtering is disabled.
In any case, I expect further reduction of memory (marginal) and CPU (of interest) footprint can be gained when cosmetic filtering is disabled by not injecting the portion of content script code which purpose is to deal with cosmetic filtering.
Current idea would be to have two versions of contentscript_end.js, one for when cosmetic filtering is enabled, another for when it is disabled, and use chrome.tabs.executeScript to manually inject one or the other.
Worries: that manually injecting causes the injected content scripts to be executed in a delayed way as opposed to declarative injecting. Need to prototype and test.
Disabling cosmetic filtering (aka ABP's "element hiding") is a big contributor to memory and CPU footprint, and specifically disabling cosmetic filtering (from the 3rd-party filters tab) feature is an easy way to decrease significantly memory and CPU footprint, which may come in handy for users browsing on less poweful devices.
Not sure how often cosmetic filtering is disabled.
In any case, I expect further reduction of memory (marginal) and CPU (of interest) footprint can be gained when cosmetic filtering is disabled by not injecting the portion of content script code which purpose is to deal with cosmetic filtering.
Current idea would be to have two versions of
contentscript_end.js, one for when cosmetic filtering is enabled, another for when it is disabled, and use chrome.tabs.executeScript to manually inject one or the other.Worries: that manually injecting causes the injected content scripts to be executed in a delayed way as opposed to declarative injecting. Need to prototype and test.