The default bug view has changed. See this FAQ.

Very high style-sets memory usage with AdBlock Plus

RESOLVED FIXED in mozilla41

Status

()

Core
CSS Parsing and Computation
--
major
RESOLVED FIXED
3 years ago
5 months ago

People

(Reporter: mancha, Assigned: heycam)

Tracking

(Blocks: 2 bugs)

Trunk
mozilla41
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P1], URL)

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Firefox 28.0 (x86 Win7) RAM usage increases drastically when rendering http://vimcolorschemetest.googlecode.com/svn/html/index-c.html. On test system, FF grinds to a halt.

According to about:memory, window-objects->layout->style-sets is the epicenter of the usage (jumping about 1 GB):

baseline      2.57 MB (48.31%)
post-render   1.01 GB (95.53%)

Quick & dirty resource profiling of MSIE10 and Chrome (same system and url) reveals significantly smaller RAM increases:

RAM delta:
----------
MSIE10          32 MB
Chrome         123 MB
Component: General → CSS Parsing and Computation
Product: Firefox → Core
Whiteboard: [MemShrink]
On Nightly, this page is using about 200mb total for me.  Can you reproduce this in safe mode?
(Reporter)

Comment 2

3 years ago
I didn't think to test safe mode because I had received independent confirmation of the problem - I apologize for the oversight.

Let me improve this report's SNR by adding that the problem lies with the Adblock Plus add-on. I will follow-up with ADP's dev team directly.

Thank you.
Summary: Extreme resource consumption (RAM) → Very high style-sets memory usage with AdBlock Plus
I'm able to reproduce on FF 28 on Mac. Firefox briefly froze while loading the page, and the page is taking over 1700 MiB. There are over 400 window objects within the page, and they all look very similar to this one:

│  │  │  ├──────4.00 MB (00.12%) -- window(http://vimcolorschemetest.googlecode.com/svn/html/tetragrammaton-c.html)
│  │  │  │      ├──3.77 MB (00.12%) -- layout
│  │  │  │      │  ├──3.68 MB (00.11%) ── style-sets
│  │  │  │      │  ├──0.03 MB (00.00%) ── pres-shell
│  │  │  │      │  ├──0.03 MB (00.00%) ++ frames
│  │  │  │      │  ├──0.01 MB (00.00%) ── pres-contexts
│  │  │  │      │  ├──0.01 MB (00.00%) ── style-contexts
│  │  │  │      │  ├──0.01 MB (00.00%) ── rule-nodes
│  │  │  │      │  └──0.00 MB (00.00%) ── line-boxes
│  │  │  │      ├──0.17 MB (00.01%) ++ js-compartment(http://vimcolorschemetest.googlecode.com/svn/html/tetragrammaton-c.html, about:blank)
│  │  │  │      ├──0.05 MB (00.00%) ++ dom
│  │  │  │      ├──0.01 MB (00.00%) ── proto-iface-cache
│  │  │  │      └──0.00 MB (00.00%) ── style-sheets

However, in a trunk build (FF31) on the same machine, loading was much faster, and memory consumption is only 205 MiB for the page. Most of the window objects look like this:

│  │  │  ├────0.48 MB (00.13%) -- window(http://vimcolorschemetest.googlecode.com/svn/html/tetragrammaton-c.html)
│  │  │  │    ├──0.26 MB (00.07%) -- layout
│  │  │  │    │  ├──0.17 MB (00.05%) ── style-sets
│  │  │  │    │  ├──0.03 MB (00.01%) ── pres-shell
│  │  │  │    │  ├──0.03 MB (00.01%) ++ frames
│  │  │  │    │  ├──0.01 MB (00.00%) ── pres-contexts
│  │  │  │    │  ├──0.01 MB (00.00%) ── style-contexts
│  │  │  │    │  ├──0.01 MB (00.00%) ── text-runs
│  │  │  │    │  ├──0.00 MB (00.00%) ── rule-nodes
│  │  │  │    │  └──0.00 MB (00.00%) ── line-boxes
│  │  │  │    ├──0.16 MB (00.04%) ++ js-compartment(http://vimcolorschemetest.googlecode.com/svn/html/tetragrammaton-c.html)
│  │  │  │    ├──0.05 MB (00.01%) ++ dom
│  │  │  │    └──0.01 MB (00.00%) ── style-sheets

dbaron, any idea what change might have fixed this?

I'm happy to mark this as WORKSFORME.
Oh, my FF28 beta also has AdBlock Plus installed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---

Comment 5

3 years ago
I can confirm this on OS X with Firefox 28 and current Firefox 30 nightly. From all I can tell, there is nothing special about this page. It's rather that having Adblock Plus installed adds ~3 MB to style-sets for each webpage (confirmed on Google start page). The issue with the page in question is that it has so many frames - and each of these frames adds 3 MB.

The likely cause is the global stylesheet that Adblock Plus installs via nsIStyleSheetService. The size of that stylesheet is currently 2.8 MB in my test profile. Roughly 50% of that stylesheet is bound to specific domains via @-moz-document, the rest is generic. Seeing it introduce significant costs for each document is news to me, I always assumed that there is only one instance of it in memory.
Blocks: 467520
OS: Windows 7 → All
Hardware: x86 → All
Version: 28 Branch → Trunk
Goodness. If ABP is indeed incurring a ~3 MiB hit for every iframe, that's really bad.
Yep. I loaded TechCrunch.com (roll over all the like images to ensure the relevant iframes get loaded). In a new profile without ABP, 'resident' was 298 MiB. With ABP, it was 526 MiB. A big chunk of that (about 120 MiB?) is due to the style sets. Compare this:

│   │  │  │  ├───1.36 MB (00.67%) -- window(http://www.facebook.com/plugins/like.php?app_id=&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter%2FwTH8U0osOYl.js%3Fversion%3D40%23cb%3Df2fe3d36ca75caa%26domain%3Dtechcrunch.com%26origin%3Dhttp%253A%252F%252Ftechcrunch.com%252Ff773654d803ce6%26relation%3Dparent.parent&href=http%3A%2F%2Ftechcrunch.com%2F2014%2F03%2F26%2Ftwitter-files-for-lawsuits-in-turkish-courts-to-challenge-the-countrys-access-ban%2F%3Fncid%3Dfacebook_social_share&layout=button_count&locale=en_US&sdk=joey&send=false&show_faces=false)
│   │  │  │  │   ├──0.91 MB (00.45%) ++ js-compartment(http://www.facebook.com/plugins/like.php?app_id=&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter%2FwTH8U0osOYl.js%3Fversion%3D40%23cb%3Df2fe3d36ca75caa%26domain%3Dtechcrunch.com%26origin%3Dhttp%253A%252F%252Ftechcrunch.com%252Ff773654d803ce6%26relation%3Dparent.parent&href=http%3A%2F%2Ftechcrunch.com%2F2014%2F03%2F26%2Ftwitter-files-for-lawsuits-in-turkish-courts-to-challenge-the-countrys-access-ban%2F%3Fncid%3Dfacebook_social_share&layout=button_count&locale=en_US&sdk=joey&send=false&show_faces=false)
│   │  │  │  │   ├──0.30 MB (00.15%) -- layout
│   │  │  │  │   │  ├──0.21 MB (00.10%) ── style-sets
│   │  │  │  │   │  ├──0.06 MB (00.03%) ── pres-shell
│   │  │  │  │   │  ├──0.01 MB (00.01%) ── style-contexts
│   │  │  │  │   │  ├──0.01 MB (00.01%) ── rule-nodes
│   │  │  │  │   │  ├──0.01 MB (00.00%) ── frames/sundries
│   │  │  │  │   │  ├──0.00 MB (00.00%) ── pres-contexts
│   │  │  │  │   │  └──0.00 MB (00.00%) ── line-boxes
│   │  │  │  │   ├──0.09 MB (00.05%) ── style-sheets
│   │  │  │  │   └──0.05 MB (00.02%) ++ dom

to this:

│  │  │  ├────4.87 MB (01.18%) -- window(http://www.facebook.com/plugins/like.php?app_id=&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter%2FwTH8U0osOYl.js%3Fversion%3D40%23cb%3Df2e8c14fe001062%26domain%3Dtechcrunch.com%26origin%3Dhttp%253A%252F%252Ftechcrunch.com%252Ff236ed077bfe652%26relation%3Dparent.parent&href=http%3A%2F%2Ftechcrunch.com%2F2014%2F03%2F26%2Fscribd-lonely-planet%2F%3Fncid%3Dfacebook_social_share&layout=button_count&locale=en_US&sdk=joey&send=false&show_faces=false)
│  │  │  │    ├──3.81 MB (00.92%) -- layout
│  │  │  │    │  ├──3.72 MB (00.90%) ── style-sets
│  │  │  │    │  ├──0.06 MB (00.02%) ── pres-shell
│  │  │  │    │  ├──0.01 MB (00.00%) ── style-contexts
│  │  │  │    │  ├──0.01 MB (00.00%) ── rule-nodes
│  │  │  │    │  ├──0.01 MB (00.00%) ── frames/sundries
│  │  │  │    │  ├──0.00 MB (00.00%) ── pres-contexts
│  │  │  │    │  ├──0.00 MB (00.00%) ── line-boxes
│  │  │  │    │  └──0.00 MB (00.00%) ── text-runs
│  │  │  │    ├──0.91 MB (00.22%) ++ js-compartment(http://www.facebook.com/plugins/like.php?app_id=&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter%2FwTH8U0osOYl.js%3Fversion%3D40%23cb%3Df2e8c14fe001062%26domain%3Dtechcrunch.com%26origin%3Dhttp%253A%252F%252Ftechcrunch.com%252Ff236ed077bfe652%26relation%3Dparent.parent&href=http%3A%2F%2Ftechcrunch.com%2F2014%2F03%2F26%2Fscribd-lonely-planet%2F%3Fncid%3Dfacebook_social_share&layout=button_count&locale=en_US&sdk=joey&send=false&show_faces=false)
│  │  │  │    ├──0.09 MB (00.02%) ── style-sheets
│  │  │  │    ├──0.05 MB (00.01%) ++ dom
│  │  │  │    └──0.00 MB (00.00%) ── property-tables
Bear with me for a second here.

The relevant number is the one computed by nsStyleSet::SizeOfIncludingThis, right?

This includes two pieces:

1)  The stylesheets themselves.  These are in fact shared across all documents, if nsIStyleSheetService is being used, as far as I can tell.  However the memory reporting setup multiple-counts them, also as far as I can tell!  It can correctly handle multiple clones of the same sheet (because then it will only report the inner from one of the clones), but it can't handle the same nsIStyleSheet pointer being in multiple style sets...

I wonder whether we should skip reporting UA/user sheets that are in a style set and also in the stylesheet service under the style set and report them under the stylesheet service, and how that would affect the numbers being seen here.

2)  The rule cascade data.  This is a per-document (e.g. because it depends on media queries and whatnot) representation of the style data.  Bug 77999 covers sharing it across documents.
Interesting... DMD is being flaky on my laptop so I won't be able to check for double-counting until I get home from the JS work week. 

But I just remeasured with and without ABP. 'explicit' was 213 MiB higher with ABP, and 'resident' was 241.6 MiB. Those two measurements are usually similar, so if the ~130 MiB of style-sets is bogus, then there's a big chunk of difference between them that's not being accounted for.
It's entirely possible that I somehow missed how we avoid double-counting for the sheets themselves.  It's also possible that somehow the sheets themselves are not that big and all the memory is the rule cascades...
We have distinct 'layout/style-sets' and 'style-sheets' numbers. I can't remember exactly what gets measured in each one.
style-sheets measures the sheets a document has a direct reference to.

Actually, I think I see what got me confused about the double-counting: nsTArray::SizeOfExcludingThis does NOT measure the array entries recursively, unlike what hashtables do.

So the style set number is not in fact including the sheets themselves, just the rule cascades.  Wladimir, do you have a link to the actual stylesheet being used here?  It looks like the rule cascade does in fact filter out non-applicable @moz-document bits, but I want to verify that that's the case.
It would be interesting to know both which parts of the RuleCascadeData are big, and what the style sheets causing this look like.
Flags: needinfo?(trev.moz)

Comment 14

3 years ago
Created attachment 8397646 [details]
Global stylesheet being used

Attached the stylesheet (adblockplus/elemhide.css in the Firefox profile). This one is from my test profile, regular users should have fewer filter lists and consequently a smaller stylesheet.

The issue doesn't look like double-counting. I checked the URL from comment 0 again and it does increase memory usage by more than 1 GB (checked with Activity Monitor on OS X).
Flags: needinfo?(trev.moz)
Status: REOPENED → NEW
Hrm.  So I tried creating a simple page with just that stylesheet (as a document sheet, not a user or UA sheet, fwiw).

I see a bunch of memory (14MB) taken by the sheet itself, under "style-sheets".  I see 0.2MB memory usage under layout/style-sets for that page, though.

It looks like every single rule in that sheet is inside @-moz-document rules, though, which would not get added to the rule cascade unless the URL matches.  If I force them all to match on any URL, I see about 6MB usage under layout/style-sets.

Comment 5 was talking about a sheet about half of which is not inside @-moz-document rules.  Any chance of seeing what that sheet looks like?
Flags: needinfo?(trev.moz)
Ah, the elemhide.css from a no-customization adblockplus install looks quite different.
Created attachment 8398328 [details]
elemhide.css I see
Er, but that still has everything inside @-moz-document...  What am I missing?
Flags: needinfo?(trev.moz)
Oh, I see what I'm missing.  One of those rules is just @-moz-document url-prefix("http://") (and a few other protocols, but not file:).

Now I get about 3MB of style-sets.  Let me see how it breaks down...
Created attachment 8398342 [details] [diff] [review]
Patch that adds some extra logging

The output from that is:

RuleHash.mIdTable: 545280
RuleHash.mClassTable: 1070080
RuleHash.mTagTable: 10880
RuleHash.mUniversalRules: 48
Pseudo-element hashes: 0
State selectors: 0
ID selectors: 394400
Class selectors: 787808
Possibly-negated class selectors: 0
Possibly-negated ID selectors: 0
Attribute selectors: 4608
Anon box rules: 2048
RuleHash.mUniversalRules: 48
Pseudo-element hashes: 0
State selectors: 32
ID selectors: 1024
Class selectors: 1024
Possibly-negated class selectors: 0
Possibly-negated ID selectors: 0
Attribute selectors: 1024
Anon box rules: 2048

which mostly says that we have lots of id/class rules in there.  Which is pretty obvious from the sheet too.

Specifically, there are about 6250 ID rules and about 6900 class rules.  I assume the reason the class tables are so much bigger than the id tables is that they had an extra doubling....

In any case, for the rulehash id table that comes out to about 87 bytes per selector.  The entries there are RuleHashTableEntry, which contain a PLDHashNumber and then an nsAutoTArray<RuleValue, 1>.  The nsAutoTArray is 16 bytes (on 64-bit) bytes plus sizeof(RuleValue).  A RuleValue is 2 pointers, a 4-byte int, and an array of 4 4-byte ints (the ancestor hashes).

So putting all that together we get 4 (PLDHashNumber) + 4 (padding) + 16 + 16 + 20 = 60 bytes.  Maybe 64 if the next thing needs to be 8-byte aligned.  That's not that much smaller than 87, given that hashtables are typically not fully loaded.  Note that pldhash will resize once the load factor hits 0.75.

Similarly, for the "ID selectors" table we have a PLDHashNumber, then a poiner, then an nsAutoTArray containing 2 pointers.  That's 4 + 4 + 8 + 16 + 2*8 = 48 bytes per entry.  The actual number above is about 63 bytes per entry.

For the class tables, which I believe contain the same entry types, I'm seeing 155 and 114 bytes respectively, which seems a tad bit high, but means a load factor of about 0.4.  When pldhash resizes, it doubles, so typically goes to a load factor of 0.375, which is consistent with the above.

I guess the moral of the story is that we pay something like 2*(48+60) = 216 bytes per rule for those hashtables (assuming a load factor of 0.5).  Once you have 13000 rules, as here, that's 2.8MB.
Thanks for the analysis, bz. It all sounds quite reasonable, except for the fact that we duplicate this stuff for every iframe. Any way to avoid that?
I was thinking about that yesterday.  It's not quite trivial.  Especially for this stylesheet, due to its use of moz-document rules.  See the (oldish) discussion in bug 77999.

In particular, the whole point of the rulehash is to have a _sorted_ (in the order they get applied in) representation of the rules that actually apply to the document.  For this particular stylesheet that means you get different rulehashes depending on which moz-document rules did or did not match.  :(

In particular, it means that even with bug 77999 fixed there will be no sharing between a document that matches any of these @moz-document rules and another document that doesn't match that rule.
Whiteboard: [MemShrink] → [MemShrink:P1]

Comment 23

3 years ago
I'm seeing this on a regular basis on my machine and I'm wondering what information I could gather to try and dig into whether it's the exact same issue discussed here, a related one, or something else. For example, this session's been alive for a day or two:

227.71 MB (100.0%) -- window-objects
├──168.50 MB (74.00%) -- layout
│  ├──145.42 MB (63.86%) ── style-sets
│  ├────9.23 MB (04.05%) ── pres-shell
│  ├────7.35 MB (03.23%) ── frames
│  ├────3.69 MB (01.62%) ++ (4 tiny)
│  └────2.81 MB (01.23%) ── style-contexts
├───35.53 MB (15.60%) -- dom
│   ├──16.64 MB (07.31%) ── orphan-nodes
│   ├───9.61 MB (04.22%) ── element-nodes
│   ├───7.25 MB (03.18%) ── text-nodes
│   └───2.02 MB (00.89%) ++ (4 tiny)
├───22.84 MB (10.03%) ── style-sheets
└────0.84 MB (00.37%) ── property-tables

In about:memory I don't see any particular windows with heavy style-sheets usage, but I do see something in the neighborhood of 1-3mb for each one I looked at. (I do have adblock plus installed.)

If I restart the browser, style-sets memory when it comes back up (same set of tabs) is ~48mb, but focusing the tabs (so they load) makes it climb all the way up to where it was (and further; I think some of the tabs were no longer resident.) So this seems to not be a leak so much as just a cost for having all these tabs open.

Updated

3 years ago
Blocks: 1001426
I just wrote a blog post about ABP's effect on Firefox's memory usage (https://blog.mozilla.org/nnethercote/2014/05/14/adblock-pluss-effect-on-firefoxs-memory-usage/), in order to raise awareness of this issue.

Comment 25

3 years ago
Any way of letting addon vendors build with something other than what requires @moz-document rules?
I tried disabling ABP on bugzilla.mozilla.org, but I still see the high "style-sets" numbers for pages from that domain. Hmm.

Comment 27

3 years ago
(In reply to Nicholas Nethercote [:njn] from comment #26)
> I tried disabling ABP on bugzilla.mozilla.org, but I still see the high
> "style-sets" numbers for pages from that domain. Hmm.

It's a global stylesheet - Adblock Plus cannot prevent Firefox from applying it to every single page opened in the browser. We merely make sure it doesn't have any effect.
> Any way of letting addon vendors build with something other than what requires
> @moz-document rules?

We could add something where sheets are registered on a per-URI basis instead of globally; that would require having lots of stylesheets in the adblock plus case.

Comment 29

3 years ago
Could you do per-URI stylesheets and then ABP could create them on-demand the first time it sees a request start at that URI?
Yes.

Comment 31

3 years ago
I don't think it will do all that much to resolve the issue here. I checked EasyList now: currently it seems to have 13521 selectors that will apply on any website (https://hg.adblockplus.org/easylist/file/29294f21dd90/easylist/easylist_general_hide.txt) and 9251 site-specific selector (https://hg.adblockplus.org/easylist/file/29294f21dd90/easylist/easylist_specific_hide.txt). So while I would highly appreciate per-URI stylesheets, they won't reduce memory usage significantly.

Is bug 77999 something that can still potentially be fixed? Then it would make sense to register the generic rules separately from the site-specific ones - the first (larger) stylesheet could be shared across all websites then.
Per-URI stylesheets are already possible via nsIDOMWindowUtils loadSheet and removeSheet methods, combined with window tracking.

Comment 33

3 years ago
Interesting, implemented in Gecko 18 and never documented. Thank you for pointing this out, that's definitely something to consider - even if we keep using the same stylesheet everywhere, injecting it into individual documents rather than registering it globally might be a good idea, that would solve quite a few issues.

Comment 34

3 years ago
(In reply to Wladimir Palant from comment #31)
> I don't think it will do all that much to resolve the issue here. I checked
> EasyList now: currently it seems to have 13521 selectors that will apply on
> any website
> (https://hg.adblockplus.org/easylist/file/29294f21dd90/easylist/
> easylist_general_hide.txt)
Too few of them apply to each web page, I can imagine.
Yesterday I tried different combinations of, disabling all site-specific filters and changing -moz-binding to display: none. That didn't make any significant difference. (We limit our filters to web pages, by accident I removed that check and memory increased 2x, presumably because the style sheets was applied to all chrome documents!) I also added some special logging and most memory seems to be used by the rule-processor referenced by the style-set, around 90% or more.

Judging by these measurements, just loading style sheets per domain is not going help, because our global style sheets are so large. We need to find a way to reduce that memory.

I don't really understand much about how the rule-processor works, but it seems like it's using a ton of hashmaps and other data structures. Would it be possible to reduce those at the expense of some performance?
The whole point of he rule processor code is to squeeze out every bit of selector matching performance we can.  So of course you can trade off performance for less memory usage there.  Finding ways to only lose a _little_ performance while decreasing memory usage significantly might take some thought, on the other hand.  In particular, you really need O(1) data structures, because O(N), especially with the sort of N we're talking about in this bug, means your performance gets a lot worse immediately.
And anyway, the real long-term solution here is probably bug 77999, like I said in comment 8.
This is interesting: https://github.com/gorhill/httpswitchboard/wiki/Adblock-Plus-memory-consumption

Comment 39

3 years ago
Yes, if a broken implementation is accepted then things can be improved of course :)

What he euphemistically puts as "87% of the filters work" actually means that only the simplest filters are supported. And even these filters won't work correctly on websites that are changing dynamically. Plus his implementation produces a potentially significant hang when the page loads.

Comment 40

3 years ago
(In reply to Kris Maglione [:kmag] from comment #32)
> Per-URI stylesheets are already possible via nsIDOMWindowUtils loadSheet and
> removeSheet methods, combined with window tracking.

For reference, filed https://issues.adblockplus.org/ticket/521 on using this in Adblock Plus.

Comment 41

3 years ago
And a follow-up to stop using @-moz-document: https://issues.adblockplus.org/ticket/524. Once this is implemented we should have a large generic stylesheet (something that bug 77999 should help with eventually) and a relatively small site-specific stylesheet.
Thanks for the updates, Wladimir! Great to see some movement here.

Comment 43

3 years ago
> What he euphemistically puts as "87% of the filters work" actually means that only the simplest filters are supported. And even these filters won't work correctly on websites that are changing dynamically. Plus his implementation produces a potentially significant hang when the page loads.

This is a terrible comment -- I really thought I was helping here.

The basic proof of concept is what matters and not one specific technical comment from you, but rather vague (and false statements: "simplest filters"?) The proof of concept was to actually support those filters you said are at the root of the problem, the ones without a specific domain.

We can get technical here, so I would like some specifics:

- What exactly are you calling "simplest filters"?

- Regarding "a potentially significant hang when the page loads", find a web page where said problem occurs (keep in mind the 20,000 CSS rules on every page is a real problem *now*). What the code does is significantly more trivial than what all complicated web pages do nowaday with their huge js framework. Before the proof of concept I did wonder whether that would be a problem, and I can tell it is definitely not, certainly not compared to injecting indiscriminately 20,000 CSS rules on every page/frame.

Also, before I even saw your comment regarding dynamically loaded page, this was already solved -- this was already planned of course (to make ads disappear in mail.google.com). Support is now 99%, and code has been optimized further.

If you don't like the solution, fine, but keep it clean please by not making up vague falsities.

Comment 44

3 years ago
Wow. Really bad. +2gigs of memory and minute load time with total GUI freeze.
Also it's quite bad with an empty profile too, +260 megs and 25-30s load time, and I still get a shorter GUI freeze. With Opera 12.17 it's +60Mb and 10 seconds, without any GUI freezes.

Comment 45

3 years ago
What is a little bit strange: Me and others see firefox memory consumption grow and grow, and never go down. See https://support.mozilla.org/de/questions/998289?fpa=1

Maybe ABP uses a lot of memory for style sheets, but why is this memory never freed when leaving a page?
Jens, that link talks about the problem being present in safe mode, so it has nothing to do with this bug.

Could you please file a separate bug on that issue and attach the relevant about:memory output to that bug?  That would help enormously!
Flags: needinfo?(bugzilla.mozilla.org)

Comment 47

3 years ago
I have not enuf information for a new bug.
Flags: needinfo?(bugzilla.mozilla.org)
You say you're seeing the memory grow... Just attach the about:memory output once it's grown, please.

Comment 49

3 years ago
An idea how to solve this: (pls keep in mind that I'm not familiar of Firefox's architecture)

Handle the Frames differently:
If you have a normal HTML page and the js adds certain objects to it then all css rules are applied to these new objects.

Couldn't we handle the frames as a part of the page and apply global css files just through like with per js added objects?


Another idea:
once the page is rendered/loaded: do we need to keep it completely in memory
or is there a way to kinda compress/merge it all after the page is rendered/loaded (when resources are available again->wouldn't effect performance too much if it is done afterwards)

Comment 50

3 years ago
(In reply to Wladimir Palant from comment #39)
> What he euphemistically puts as "87% of the filters work" actually means
> that only the simplest filters are supported. And even these filters won't
> work correctly on websites that are changing dynamically. Plus his
> implementation produces a potentially significant hang when the page loads.

I will let the code speaks for itself: https://www.youtube.com/watch?v=X8tGAPYLGtI

Comment 51

3 years ago
(In reply to R. Hill from comment #50)
> I will let the code speaks for itself: µBlock: Memory and CPU usage

On the other hand what you're showing has nothing to do with firefox since it's a chrome only extension.

Comment 52

3 years ago
(In reply to avada from comment #51)
> On the other hand what you're showing has nothing to do with firefox since
> it's a chrome only extension.

I believe he was trying to show that it isn't a firefox (only) issue.
Is any work in progress to resolve this issue? There weren't any comments for a while. uBlock is now available also for Firefox so I guess we can use it instead ABP as a workaround. I don't want to advertise it, but overhead is almost non-existent on the test site from this bug.

Comment 54

2 years ago
(In reply to Kacper from comment #53)
> Is any work in progress to resolve this issue? There weren't any comments
> for a while. uBlock is now available also for Firefox so I guess we can use
> it instead ABP as a workaround. I don't want to advertise it, but overhead
> is almost non-existent on the test site from this bug.

Well, I made the switch, but...

I visited the url, and firefox instantly became unresponsive and useless. Memory usage kept increasing until there wasn't any more and firefox crashed.

Actually it happens when I disable ublock....
Any other other that's known to cause the same issue?

Comment 55

2 years ago
I found a tolerable workaround for myself, where the aim was to reduce the size of the elemhide.css. With my filter subscriptions and quite a few self-made filters, the file was at 3.9 MB before my workaround, now it's at 577kB, so everything is 85% less bad. :-)

In my Firefox I also have RequestPolicy and noscript installed, so a typical cross-domain ad request will be blocked by RP anyway, even if there is a missing entry in ABP. That is to say, there should be no problem with lower security due to a missing ABP entry in this setup.
So I made use of ABP's great statistics to find out which filters were used at least once in the last 4 years. I copied all those into a txt file, removed duplicates with
> sort -u unsorted.txt > unique.txt
and pasted the result into a custom list "best of subscriptions" in ABP. Firefox is at 100% CPU for several minutes after the paste, but it works. Of course I then removed all my subscriptions.

It's simple and effective and maybe others haven't thought of this as well.
I actually wrote some code that splits elemhide.css in two. It would only contain global selectors and all the domain specific selectors would be injected in a new css file per page and domain. However this didn't change style-set usage at all, is that something that Firefox already optimizes?

Comment 57

2 years ago
I get this around as bad as with ABP even when I disable it.
So what other extensions cause this? Or at least what kind should I look for?
I tried disabling stylish but it had no effect.

Comment 58

2 years ago
How are you disabling ABP? At least according to https://adblockplus.org/blog/on-the-adblock-plus-memory-consumption#c005357, disabling on a single page won't work. OTOH, if you are disabling the extension using the extension manager, then I guess it ought to be gone after restarting Firefox.

Comment 59

2 years ago
(In reply to Nuno Silva from comment #58)
> How are you disabling ABP? At least according to
> https://adblockplus.org/blog/on-the-adblock-plus-memory-consumption#c005357,
> disabling on a single page won't work. OTOH, if you are disabling the
> extension using the extension manager, then I guess it ought to be gone
> after restarting Firefox.

Hi!

I disabled the addon completely in the manager.

Comment 60

2 years ago
And the memory usage in the URL in this bug after starting Firefox with ABP disabled is as high as with ABP enabled with EasyList? A couple months or so ago, I did the test, and removing the problematic EasyList entries reduced memory consumption considerably.

If your issue still happens with ABP disabled, then perhaps you should fill a separate bug, that is not related to ABP?

Comment 61

2 years ago
In addition to ABP, ProxMate Beta...
> https://addons.mozilla.org/en-US/firefox/addon/proxmate-beta/
... is very capable of messing up the memory situation for me.

Comment 62

2 years ago
(In reply to Nuno Silva from comment #60)
> And the memory usage in the URL in this bug after starting Firefox with ABP
> disabled is as high as with ABP enabled with EasyList? A couple months or so
> ago, I did the test, and removing the problematic EasyList entries reduced
> memory consumption considerably.


I don't even use ABP anymore (ublock instead.) At first I thought it was causing the same issue, but it turned out that on a new profile it didn't. So some other addons might be guilty. (or whatever firefox settings.)

 
> If your issue still happens with ABP disabled, then perhaps you should fill
> a separate bug, that is not related to ABP?

Without knowing what causes it would be pretty pointless in my opinion.
This bug is related to ABP. For general information that may enable you to gather information for filing a bug,or solving issues please see https://support.mozilla.org/kb/firefox-uses-too-much-memory-ram#w_memory-troubleshooting-tools
(Assignee)

Updated

2 years ago
Depends on: 77999
Bug 77999, which landed for Firefox 41, helps a good bit here.  See bug 77999 comment 46.
(In reply to David Baron [:dbaron] ⏰UTC-7 from comment #64)
> Bug 77999, which landed for Firefox 41, helps a good bit here.  See bug
> 77999 comment 46.

I've done some measurements and I'm confident to declare it helps more than "a good bit"; it completely fixes it. E.g. the memory usage of the test case from comment drops by ~1550 MiB, bringing memory usage entirely down to normal levels.

Great work, heycam!
Status: NEW → RESOLVED
Last Resolved: 3 years ago2 years ago
Resolution: --- → FIXED
Assignee: nobody → cam
Target Milestone: --- → mozilla41

Comment 66

2 years ago
This is a major improvement. Perhaps an announcement should be made through blog.
(In reply to mayankleoboy1 from comment #66)
> This is a major improvement. Perhaps an announcement should be made through
> blog.

Yes, but see bug 77999 comment 57.
See bug 77999 comment 58 for the relnote nomination and link to the blog post.
You need to log in before you can comment on or make changes to this bug.