Categories
about:memory AdBlock Plus Firefox Memory consumption MemShrink

Firefox 41 will use less memory when running AdBlock Plus

Last year I wrote about AdBlock Plus’s effect on Firefox’s memory usage. The most important part was the following.

First, there’s a constant overhead just from enabling ABP of something like 60–70 MiB. […] This appears to be mostly due to additional JavaScript memory usage, though there’s also some due to extra layout memory.

Second, there’s an overhead of about 4 MiB per iframe, which is mostly due to ABP injecting a giant stylesheet into every iframe. Many pages have multiple iframes, so this can add up quickly. For example, if I load TechCrunch and roll over the social buttons on every story […], without ABP, Firefox uses about 194 MiB of physical memory. With ABP, that number more than doubles, to 417 MiB.

An even more extreme example is this page, which contains over 400 iframes. Without ABP, Firefox uses about 370 MiB. With ABP, that number jumps to 1960 MiB.

(This description was imprecise; the overhead is actually per document, which includes both top-level documents in a tab and documents in iframes.)

Last week Mozilla developer Cameron McCormack landed patches to fix bug 77999, which was filed more than 14 years ago. These patches enable sharing of CSS-related data — more specifically, they add data structures that share the results of cascading user agent style sheets — and in doing so they entirely fix the second issue, which is the more important of the two.

For example, on the above-mentioned “extreme example” (a.k.a. the Vim Color Scheme Test) memory usage dropped by 3.62 MiB per document. There are 429 documents on that page, which is a total reduction of about 1,550 MiB, reducing memory usage for that page down to about 450 MiB, which is not that much more than when AdBlock Plus is absent. (All these measurements are on a 64-bit build.)

I also did measurements on various other sites and confirmed the consistent saving of ~3.6 MiB per document when AdBlock Plus is enabled. The number of documents varies widely from page to page, so the exact effect depends greatly on workload. (I wanted to test TechCrunch again, but its front page has been significantly changed so it no longer triggers such high memory usage.) For example, for one of my measurements I tried opening the front page and four articles from each of nytimes.com, cnn.com and bbc.co.uk, for a total of 15 tabs. With Cameron’s patches applied Firefox with AdBlock Plus used about 90 MiB less physical memory, which is a reduction of over 10%.

Even when AdBlock Plus is not enabled this change has a moderate benefit. For example, in the Vim Color Scheme Test the memory usage for each document dropped by 0.09 MiB, reducing memory usage by about 40 MiB.

If you want to test this change out yourself, you’ll need a Nightly build of Firefox and a development build of AdBlock Plus. (Older versions of AdBlock Plus don’t work with Nightly due to a recent regression related to JavaScript parsing). In Firefox’s about:memory page you’ll see the reduction in the “style-sets” measurements. You’ll also see a new entry under “layout/rule-processor-cache”, which is the measurement of the newly shared data; it’s usually just a few MiB.

This improvement is on track to make it into Firefox 41, which is scheduled for release on September 22, 2015. For users on other release channels, Firefox 41 Beta is scheduled for release on August 11, and Firefox 41 Developer Edition is scheduled to be released in the next day or two.

21 replies on “Firefox 41 will use less memory when running AdBlock Plus”

IIRC unrestored tabs are about:blank documents until they are restored, so yes this will reduce the memory taken by these tabs by the ~90 KiB needed for the user agent style sheets.

Alright. If I’m doing my math correctly, a hundred unrestored tabs would translate to a little over 9 MB.
So not a whole lot altogether. (unless I missed something)

Do you have any benchmarks on how this affects actual perceived performance, such as load and render time?

The only data I have there is from Cameron’s comment at https://bugzilla.mozilla.org/show_bug.cgi?id=77999#c54, which says:

I measured how long it takes to build the rule cascade for the agent-level sheets (i.e. all of the built-in UA style sheets), and that’s about 0.3ms on my 2012 2.6 GHz i7 rMBP. For the user-level sheets, which is where the ABP sheet is, it’s about 13ms. So these are the times we’ll save on each page load.

The ABP “non-intrusive advertising” option can be unchecked, so that’s not such a big advantage for uBlock Origin; what is a big advantage is the ability to override exceptions with $important, block inline scripts with $inline-script, read popular HOSTS files as if they were ABP lists, and override all ABP-style blocking rules with host-based dynamic filtering rules.

It also does run more efficiently than ABP; it should stay that way even after this patch, but not by quite so much, because Raymond Hill has said that uBlock Origin wasn’t affected by this browser bug to begin with.

Hi, This are great news but I was wondering when are you going to takle the performance problem that we are facing for quite some time in Linux, specially those use graphics cards such as ATI and NVIDIA?

I love Firefox I’ve been using it for quite some time (Since the NetScape era) but I’m really tired of this (As most of the community)

Hey SomeOne.
https://bugzilla.mozilla.org/show_bug.cgi?id=1038800

If you enable these, you might be pleasantly surprised w/ the results.
Depending on the crappiness of your driver you might have to force-enable acceleration too which might cause instability (sure does on my ATI card). But I’ll take occasional tab crashing, esp w/ webgl, for the speedup.

There’s some discussion there and links to relevant bugs.

MiB means ‘mebibyte’ (1024 KiB), used for binary measurement, whereas ‘megabyte’ (1000 kB) is MB, used for decimal measurement.

It’s pretty confusing sometimes…

As for why to use it – because it’s unambiguous. Although many Linux distributions, and I believe OSX as well are now using kB, MB etc. correctly to mean 1k, 1M bytes, Windows still uses kB and MB to mean powers of 1024.

Personally I wouldn’t mind if we just used the metric prefixes for everything, so long as they *always* mean powers of 1024 when it comes to storage units – but unfortunately kb, Mb (kilobits, megabits) traditionally refer to powers of 1000, so it wouldn’t work.

Simply amazing. This always proves that there are places where even more memory can be saved when looked at from various perspectives. Keep squashing those memory hogging bugs. Where do we send the beer? 😉

This was somewhat redundant, since all Adblock Plus users should just switch to Ublock Origin anyway (it’s superior in every way)

More effort really needs to be spent on making more extensions compatible with e10s (or vice versa), especially FireIE.

“This was somewhat redundant, since all Adblock Plus users should just switch to Ublock Origin anyway (it’s superior in every way)”

I’ve seen variations on this comment many times in discussions of this post. It’s totally wrong-headed.

Here are the usage stats for these add-ons:

AdBlock Plus: 20.3 million daily users (https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/statistics/?last=30)
uBlock: 0.22 million daily users (https://addons.mozilla.org/en-US/firefox/addon/ublock/statistics/?last=30)
uBlock Origin: 0.08 million daily users (https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/statistics/?last=30)

There are ~70x as many AdBlock Plus users as there are uBlock users. Unless you personally convince all 20 million AdBlock Plus users to convert to uBlock, they won’t see any benefit. (And good luck explaining to them the uBlock vs. uBlock Origin split! What a mess that is.) Meanwhile, when Firefox 41 comes out in September, all 20 million of those AdBlock Plus users will immediately benefit, without having to lift a finger, thanks to Cameron’s patch.

Sometimes it’s worth thinking outside the tech elite bubble (the one where “everybody knows uBlock is better”) and thinking about ordinary users in the real world (where most people haven’t even heard of uBlock).

I mainly thought it was wrong-headed because this fix dealt with a general memory issue that ABP just happened to be unusually strongly affected by, rather than something specific to ABP; however, I was sure that by now nearly everyone who used any sort of ad-blocker would have heard of uBlock Origin (while just not caring enough to switch), and I thought I was late to the party when I heard about it back in October and its earliest predecessor, HTTP Switchboard, had already been around for a few months.

Ublock Origin is still much better than Adblock Plus in every way.

– This patch won’t help the higher CPU usage of Adblock Plus. So Ublock Origin has not only lower memory usage, but it has lower CPU usage too than Adblock Plus! And don’t forget the resource usage difference in Google Chrome.

– Ublock is the only existing full featured adblocker on Android. It has the same features on mobile as on desktop.

But if we’re talking about Adblock, you have to realize that it’s Android version is a limited, dumbed down addon. You can’t even use custom filters in Adblock on Android!

And not to mention the policy of Adblock with the “acceptable ads”. Nobody should support that mentality.

Comments are closed.