Closed Bug 988266 Opened 10 years ago Closed 9 years ago

Very high style-sets memory usage with AdBlock Plus

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla41

People

(Reporter: mancha1, Assigned: heycam)

References

(
URL
)

Details

(Whiteboard: [MemShrink:P1])

Attachments

(3 files)

Global stylesheet being used
2.82 MB, text/plain
Details
elemhide.css I see
2.43 MB, text/css
Details
Patch that adds some extra logging
7.72 KB, patch
Details | Diff | Splinter Review 
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?
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
Closed: 10 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---
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: abp
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)
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.
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...
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]
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.
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.
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.
(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.
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?
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.
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.
(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.
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.
(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.
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.
> 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.
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.
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)
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.
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)
(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
(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.
(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.
(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?
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?
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.
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.
(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.
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?
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.
(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
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
Closed: 10 years ago → 9 years ago
Resolution: --- → FIXED
Assignee: nobody → cam
Target Milestone: --- → mozilla41
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.

Attachment

General

Creator:
Created:
Updated:
Size: