On the Adblock Plus memory consumption · 2014-05-15 15:35 by Wladimir Palant

The news is making the rounds that the memory consumption of Adblock Plus can be considerable in some scenarios. While some scenarios mentioned (like the page that requires almost 2 GB of memory) are really edge cases, and unlikely something you will ever see during regular browsing, the issue is certainly real. It isn’t exactly unknown either and we have been looking into ways to resolve it for a while already.

Now, there are really two very different issues mentioned there. One is caused by very non-obvious behavior in Firefox: while Adblock Plus registers a single stylesheet for its element hiding feature, what happens behind the scenes is Firefox creating a new copy of it for each page being loaded (bug 988266). The memory consumption of all these copies can be very significant, like the 2 GB mentioned above for an edge case.

There is some ongoing discussion in this bug, which will hopefully result in a way to remove the duplication in Firefox and have most of the stylesheet data shared between all pages. Beyond that we are working on a feature to let users send us their filter hit statistics (optional and opt-in of course). This data should help filter authors see which filters are actually being used and which can be removed. Reducing the number of filters will also reduce the memory consumption of that stylesheet.

The other issue is the memory consumption of the data structures created by Adblock Plus itself, these are mostly required in order to manage and apply its filters. Current filter lists for Adblock Plus have around 50 thousand filters which (along with supplemental data like filter hits) require around 60 MB of memory. Clearly, that data is stored in a less than optimal way but apparently that’s hard to avoid when working with complicated JavaScript objects.

Of course we are working on identifying unnecessary memory consumption and getting rid of it (see issue 354 for example), but the potential is limited here as long as we stick to JavaScript objects. So instead we want to implement our own way to store data, a project that will hopefully be finished soon. That approach should also improve performance in the long term though it’s not quite clear yet how well the new code will perform.

Commenting is closed for this article.