Adblock Plus and (a little) more

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.


Comment [17]

  1. Rorto · 2014-05-15 17:19 · #

    To get rid of this problem, i am currently testing Privoxy.
    For easy set up, I have used this script:

  2. Alexander Peter Kowalski · 2014-05-15 17:56 · #

    This comment originally contained tons of off-topic text paired with advertising for own solution. Short version: host files are better than Adblock Plus.

  3. yeah okay · 2014-05-15 18:32 · #

    Just admit that it’s Mozilla’s fault for not rushing to replace gecko with servo and replace spidermonkey with a better js engine in rust.

  4. indy · 2014-05-16 00:49 · #


    Host-based blocking doesn’t hide elements(which otherwise makes pages very ugly and might as well not bother), and some ad-networks are self-hosted, which host-based blocking can’t work around.

    An example is my favorite 10 sites I element hide about 70 different elements of the pages to make browsing much more efficient.

    Thanks for what you do, though, it does have its uses in many other scenarios!

  5. Ferdinand · 2014-05-16 09:21 · #

    Using 100MB for adblock is okay to me if it stays at that level. The main problem in Firefox is that it becomes slow at 1+GB and adblock memory usage gets you there faster. I use UnloadTab to keep Firefox memory usage down to at most 700MB.
    Why does it use about 190MB in Chrome?

    Reply from Wladimir Palant:

    Up to 100 MB memory usage (if you don’t count spikes caused by temporary objects) is what I know as well. Memory use that’s significantly larger than that would indicate a memory leak but we aren’t currently aware of any in Adblock Plus – maybe some other extension interferes.

  6. George · 2014-05-16 21:17 · #

    Wladimir, it is good news that there’s a chance that the situation can be improved (even if not completely fixed).

    Until then, for when I’m using a machine with little memory:

    1. Does choosing “Disable on this page only” prevent high memory use on that page? (I heard that the answer is no.)

    2. Does choosing “Disable everywhere” prevent high memory use in general (without restarting Firefox)?

    And finally: is the Chrome version of Adblock Plus affected (though I woulnd’t use Chrome on a machine with little memory as I find Firefox performs much better memory-wise …)

    Reply from Wladimir Palant:

    If you are talking about the styles issue – disabling Adblock Plus everywhere “fixes” it, disabling on a particular site doesn’t (the way this works in Firefox there cannot be exceptions for individual websites). Chrome is similarly affected, disabling Adblock Plus on a website there prevents style injection however.

  7. nnethercote · 2014-05-16 22:37 · #

    I tried (1), and it doesn’t appear to have any effect.

    I haven’t tried (2), but I did try simply disabling ABP via Firefox’s add-ons manager, and that caused memory usage to drop immediately.

    I haven’t tried Chrome, but I’ve read in several places that ABP for Chrome also uses a lot of memory, though the effects are not identical.

  8. geppetto · 2014-05-18 00:08 · #

    How much is this affecting the ABP android version? Even with the (ram efficient) rooted cm4.4.2 it consumes a lot of RAM which is super precious at mobile phones…
    Will you also provided an updated .apk after any kind of optimisation? :-)

    Reply from Wladimir Palant:

    The stylesheet issue doesn’t affect Android. However, the general memory consumption of Adblock Plus is relatively high there as well – that’s the main reason why exists. That work is much more important for mobile than for the desktop browsers and of course we will update Adblock Plus for Android as soon as it is done.

  9. Andrew Ducker · 2014-05-19 14:01 · #

    Is there any reason why ABP couldn’t put in a filtered list to each page?

    I’ve just seen this:

    and it seems like a good alternative approach that would save massively on memory.

    Reply from Wladimir Palant:

    It’s because roughly 60% of the filters currently in EasyList are meant to apply on all webpages so this kind of filtering wouldn’t help much. Of course one could go there and implement an intentionally broken approach in order to claim that the performance is great if “87% of the filters” work. Fact is, with this implementation only the most simple filters are supported and even that support is very incomplete for pages that change dynamically.

    Note that the memory issue this is trying to solve isn’t very significant – except on very few webpages.

  10. Andrea Martinelli · 2014-05-19 22:00 · #

    Here’s EasyList stripped out of all its CSS rules.
    It will miss some banners, but most of them are still blocked.

    Reply from Wladimir Palant:

    Or simpler: Seems that it isn’t linked from the subscriptions list any more.

  11. James Edward Lewis II · 2014-05-28 22:23 · #

    Does the use of Shadow DOM in the Chrome version of the extension improve memory usage, compared to injecting a stylesheet normally? I’m switching back from AdBlock to ABP to check, because I noticed AdBlock hasn’t used Shadow DOM yet, even though ABP does not perform the null-content redirection (image to 1×1 transparent PNG, document to about:blank) that AdBlock performs.

    Reply from Wladimir Palant:

    No, the Shadow DOM should have no impact on the memory use whatsoever.

    ABP hides blocked elements by other means, redirecting is generally problematic due to potential conflicts with other extensions.

  12. CBA · 2014-05-29 09:58 · #

    The above doesn’t combine well with a supplementary list, like EasyList Germany, which requires the full EasyList. What I need is an EasyList “compact” (or short version), as the full EasyList is too large. Is there such a thing like “compact”?

  13. James Edward Lewis II · 2014-05-29 12:11 · #

    Rorto, I think I got that updater script working on Windows using JScript; the only dependency is sed, but the script can be refactored to use only the native capabilities of the Windows Script Host:

  14. K.L. · 2014-06-07 05:34 · #


    You might want to try out “Easylist – NoMercy”. It’s compact than Easylist. I found it on Adblock Edge.

    List URL:

    Reply from Sebastian Noack:

    It seems that it’s author confused Acceptable Ads with the whitelisting rules in EasyList, which exist to work around known issues. However, there are no Acceptable Ads whitlisted in EasyList. They are whitelisted by a separate filter list. So EasyList NoMercy will essentially just break some websites.

  15. AnonyMice and AnonyMen · 2014-06-14 23:20 · #

    Adblock Plus can use up to 60M? Pft.

    Without Adblock Plus on a fresh profile, Firefox uses some odd 150M. Doing nothing but installing Adblock Plus and fetching the EasyList filter I am seeing usage upwards of 300M.

    Granted, it’s 2014, I have the memory. But I think this is an understatement.

  16. matthieu · 2014-06-16 13:10 · #

    Adblock Plus + Firefox crashes on Facebook.
    It seems like they do not like the element hider either, but crashing your browser (“firefox has to close” and all) is a hard counterattack…

    Other than that, and with a recent computer, the memory consumption is not that much of a problem to me.

  17. CelticManiac · 2014-06-25 15:37 · #

    It’s been 40+ days since your blog post. any updates? I understand that both mozilla and abp have homeworks of their own to do so updates from any would be welcome news for abp fans

    Reply from Wladimir Palant:

    We are making progress but it really isn’t that simple. E.g. concerning the stylesheet memory issue, Tom Schuster created a patch in that will hopefully make it into Firefox soon. This will allow improvements on our end with backwards compatibility being the tough part here.

Commenting is closed for this article.