Last Comment Bug 686795 - Investigate upto 50% higher memory usage than competing browsers when viewing large changeset diffs on hg.m.o
: Investigate upto 50% higher memory usage than competing browsers when viewing...
Status: RESOLVED FIXED
[parity-IE] [parity-Opera]
:
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: mozilla18
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
https://hg.mozilla.org/tracemonkey/re...
Depends on: 674922 DMD 678376 760331 760831
Blocks: text-suck
  Show dependency treegraph
 
Reported: 2011-09-14 16:07 PDT by Ed Morley [:emorley]
Modified: 2014-02-19 07:23 PST (History)
34 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
better accounting for layout data structures (21.34 KB, patch)
2012-05-30 20:24 PDT, Nathan Froyd [:froydnj]
no flags Details | Diff | Splinter Review
better accounting for layout data structures (24.58 KB, patch)
2012-05-31 07:38 PDT, Nathan Froyd [:froydnj]
no flags Details | Diff | Splinter Review
Compressed hgweb page, part 1 (3.00 MB, application/octet-stream)
2012-07-24 06:43 PDT, Justin Lebar (not reading bugmail)
no flags Details
Compressed hgweb page, part 2 (1.31 MB, application/octet-stream)
2012-07-24 06:45 PDT, Justin Lebar (not reading bugmail)
no flags Details

Description Ed Morley [:emorley] 2011-09-14 16:07:14 PDT
In bug 678376, it was found that at that time, a certain page (listed in the URL field above) resulted in a 70%+ heap-unclassified value. That bug dealt with discovering the missing reporters (some of which have since been added), however it was also found that the memory usage for this page was much higher than other competing browsers. 

This bug is for the investigation of how to reach something close to Opera/IE parity for this page.

For example: (from http://www.neowin.net/forum/topic/989780-meet-firefox-next/page__st__720__p__594231040#entry594231040)

    Firefox 8.0a1 before patch: 2.0 GB
    Firefox 8.0a1 after patch: 1.3 GB
    Latest Chrome canary build and dev (15.0.849.0): 1.1GB
    Webkit2Process of Safari 5.1: 1.05 GB
    Internet Explorer 9.0.2: 838 MB
    Latest Opera Next 12.00: 727 MB

I've also repeated the steps in bug 678376 comment 0 using today's nightly (Win7 WOW64; 2011-09-14):

1,135.08 MB (100.0%) -- explicit
├────447.91 MB (39.46%) -- layout
│    ├──447.27 MB (39.40%) -- shell(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d)
│    │  ├──447.23 MB (39.40%) -- arenas
│    │  └────0.04 MB (00.00%) -- (1 omitted)
│    └────0.64 MB (00.06%) -- (3 omitted)
├────430.79 MB (37.95%) -- heap-unclassified
├────238.39 MB (21.00%) -- dom
├─────13.09 MB (01.15%) -- js
│     ├───9.11 MB (00.80%) -- compartment([System Principal], 0x6d62000)
│     │   └──9.11 MB (00.80%) -- (13 omitted)
│     └───3.98 MB (00.35%) -- (8 omitted)
└──────4.90 MB (00.43%) -- (4 omitted)
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2011-09-14 17:30:28 PDT
So we still have a good bit of heap-unclassified, and no visibility into the layout arenas or the particulars of the dom memory usage....
Comment 2 Johnny Stenback (:jst, jst@mozilla.com) 2011-09-20 13:47:53 PDT
We should work on finer grained reporters for dom and layout here, that would help in figuring out what to focus on here. P2 for now.
Comment 3 Nicholas Nethercote [:njn] 2012-04-17 22:44:59 PDT
Removing the MemShrink tag because it blocks tracking bug 689769 which also has the MemShrink tag.
Comment 4 Ed Morley [:emorley] 2012-05-30 07:11:27 PDT
Using today's Nightly:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1
http://hg.mozilla.org/mozilla-central/rev/65fa5cb6f79c

1,231.51 MB (100.0%) -- explicit
├────936.63 MB (76.06%) -- window-objects
│    ├──935.17 MB (75.94%) -- top(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d, id=7)/active/window(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d)
│    │  ├──528.92 MB (42.95%) -- layout
│    │  │  ├──447.84 MB (36.37%) ── arenas
│    │  │  ├───80.98 MB (06.58%) ── pres-contexts
│    │  │  └────0.10 MB (00.01%) ── style-sets
│    │  ├──406.23 MB (32.99%) ── dom [2]
│    │  └────0.02 MB (00.00%) ── style-sheets
│    └────1.45 MB (00.12%) ++ (3 tiny)
├────181.43 MB (14.73%) ── heap-unclassified
├─────40.87 MB (03.32%) ── atom-table
├─────32.17 MB (02.61%) ── history-links-hashtable
├─────21.00 MB (01.71%) ++ js
├─────15.41 MB (01.25%) -- storage
│     ├──14.06 MB (01.14%) ++ sqlite
│     └───1.35 MB (00.11%) ── prefixset/all
└──────4.00 MB (00.32%) ++ (8 tiny)
Comment 5 Nathan Froyd [:froydnj] 2012-05-30 17:59:52 PDT
Getting finer-grained stats on those huge dom numbers is going to be rough: virtually all the space is taken up by content nodes.  Not sure if it's really worth splitting out the content nodes separately, either.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2012-05-30 18:34:22 PDT
A question.  How many DOM nodes are on this page?
Comment 7 Nathan Froyd [:froydnj] 2012-05-30 20:24:12 PDT
Created attachment 628581 [details] [diff] [review]
better accounting for layout data structures

(In reply to Boris Zbarsky (:bz) from comment #6)
> A question.  How many DOM nodes are on this page?

~2.1 million, assuming just trip-counting the loop here:

http://dxr.lanedo.com/mozilla-central/content/base/src/nsDocument.cpp.html#l9702

actually counts the DOM nodes.

Some late-night hacking and grousing about slow computers produces this slightly more informative about:memory for the layout bits (x86-64 Linux):

│  │  ├──1,623.34 MB (79.18%) -- active/window(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d)
│  │  │  ├──1,002.41 MB (48.89%) -- layout
│  │  │  │  ├────453.29 MB (22.11%) ── arenas
│  │  │  │  ├────237.74 MB (11.60%) -- frames
│  │  │  │  │    ├──122.39 MB (05.97%) ── nsInlineFrame
│  │  │  │  │    ├──114.38 MB (05.58%) ── nsTextFrame
│  │  │  │  │    └────0.98 MB (00.05%) ++ (20 tiny)
│  │  │  │  ├────145.63 MB (07.10%) ── pres-contexts
│  │  │  │  ├────132.79 MB (06.48%) ── text-runs
│  │  │  │  ├─────32.80 MB (01.60%) ── line-boxes
│  │  │  │  └──────0.15 MB (00.01%) ── style-sets
│  │  │  ├────620.90 MB (30.28%) ── dom [2]
│  │  │  └──────0.04 MB (00.00%) ── style-sheets

Still a lot of stuff being allocated in the arena that we have no visibility on.

The patch for producing this is attached.  Warning: may not be suitable for children.  I'm not entirely sure about this approach.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2012-05-30 20:47:42 PDT
Yeah, that counts the nodes correctly.

620MB over 2.1e6 nodes means about 300 bytes per node.  That's ... pretty big.  I guess maybe a bunch of those are long-ish textnodes, but still...  The actual nsIContent data structure is closer to 40 bytes, last I checked.  I wonder what's using the memory.  Maybe lots of text in the textnodes?
Comment 9 Nathan Froyd [:froydnj] 2012-05-31 07:38:19 PDT
Created attachment 628732 [details] [diff] [review]
better accounting for layout data structures

v2, now with style contexts and rule nodes included.  The remaining primary culprits in arenas are a scattering of structures from nsStyleStruct.h that I didn't want to separate out individually (nsStyleUserInterface and nsStyleXUL seem to be the two biggest offenders).  We now get:

│  ├──1,623.36 MB (79.27%) -- top(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d, id=12)/active/window(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d)
│  │  ├──1,002.43 MB (48.95%) -- layout
│  │  │  ├────408.93 MB (19.97%) ── style-contexts
│  │  │  ├────237.74 MB (11.61%) -- frames
│  │  │  │    ├──122.39 MB (05.98%) ── nsInlineFrame
│  │  │  │    ├──114.38 MB (05.58%) ── nsTextFrame
│  │  │  │    └────0.98 MB (00.05%) ++ (20 tiny)
│  │  │  ├────145.63 MB (07.11%) ── pres-contexts
│  │  │  ├────132.81 MB (06.49%) ── text-runs
│  │  │  ├─────32.80 MB (01.60%) ── line-boxes
│  │  │  ├─────30.68 MB (01.50%) ── rule-nodes
│  │  │  └─────13.83 MB (00.68%) -- (2 tiny)
│  │  │        ├──13.68 MB (00.67%) ── arenas
│  │  │        └───0.15 MB (00.01%) ── style-sets
│  │  ├────620.90 MB (30.32%) ── dom [2]
│  │  └──────0.04 MB (00.00%) ── style-sheets
│  └──────1.93 MB (00.09%) ++ (3 tiny)

A *lot* of style contexts, more than 1 per DOM node.

Looks like every single context line gets a <span> of its own, even if it doesn't need to be colored (for +/- purposes).  The +/- lines also get individual style="color:FOO", rather than a common named style (as the line numbers, of all things, do); don't know if that makes a difference.  Guess the web diffs could use a little HTML optimization.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 07:59:39 PDT
> A *lot* of style contexts, more than 1 per DOM node.

Erm.  That's _really_ odd.  That really shouldn't be happening!  There should, in fact, be significantly fewer style contexts than DOM nodes, in absolute numbers, due to style context sharing!

This might be worth spinning off into a separate bug.
Comment 11 Nathan Froyd [:froydnj] 2012-05-31 09:02:39 PDT
(In reply to Boris Zbarsky (:bz) from comment #8)
> 620MB over 2.1e6 nodes means about 300 bytes per node.  That's ... pretty
> big.  I guess maybe a bunch of those are long-ish textnodes, but still... 
> The actual nsIContent data structure is closer to 40 bytes, last I checked. 
> I wonder what's using the memory.  Maybe lots of text in the textnodes?

Some hacking says:

│  │  ├────620.89 MB (36.28%) -- dom [2]
│  │  │    ├──468.68 MB (27.39%) ── element-nodes
│  │  │    ├──152.21 MB (08.89%) ── text-nodes
│  │  │    └────0.00 MB (00.00%) ── comment-nodes

Just a lot of elements, I guess.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 09:10:37 PDT
That's pretty bizarre.  We shouldn't be ending up with 200+ bytes per element!  What's going on there?
Comment 13 Nathan Froyd [:froydnj] 2012-05-31 09:34:34 PDT
Anchors appear to be clocking in at ~200 bytes, some less (~160 bytes), some much more (~272 bytes).  That's only about 100 MB of element nodes, though; not sure where the rest is coming from.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 09:40:11 PDT
Ah, right.  For anchors there's all the URI baggage...

Still, we're averaging about 200 bytes for the other ones too, and the number in my head, on 64 bit, is closer to 80 bytes.
Comment 15 Nathan Froyd [:froydnj] 2012-05-31 09:43:53 PDT
Apparently many of the anchors have URLs associated with them, and those are rather large; nsStandardUrl::SizeOfIncludingThis is routinely returning ~300 bytes.
Comment 16 Nathan Froyd [:froydnj] 2012-05-31 09:49:10 PDT
Oh, you already noted that.  Doh.  Anyway, spans are 144 bytes apiece, which if I am debugging the optimized code correctly, is all coming from child attributes.
Comment 17 Nathan Froyd [:froydnj] 2012-05-31 10:01:09 PDT
Er, extra data on spans is 144 bytes.  nsINode::SizeOfIncludingThis is saying the spans themselves are 128 bytes (malloc rounding?), for a total of 272 bytes.
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 10:42:39 PDT
Bah.  A span element in an opt build has layout like so, I believe:

  nsWrapperCache:
    1 word of vtable
    1 word for the JSObject*
  nsINode:
    1 word of vtable
    2 words nodeinfo and parent
    8 bytes flags
    5 words siblings, firstchild, primaryframe, slots
  nsIContent: 
  Element:
    8 bytes mState
  nsGenericElement:
    4 byte refcount
    1 word nsAttrAndChildArray
  nsStyledElementNotElementCSSInlineStyle:
  nsStyledElement:
  nsMappedAttributeElement:
  nsGenericHTMLElement:
  self:
    1 word vtable pointer
    
On a 64-bit system, I believe that adds up to 15*8 = 120 bytes (including the 4-byte hole between the refcount and the nsAttrAndChildArray).  I guess my memory 80-ish bytes was for just nsINode.  :(

jemalloc rounds up to multiples of 16 in this range, so we get 128.
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 10:58:22 PDT
OK., so for a typical span in that file I see something like two kids (an <a> and a textnode) and a style attribute.

So we allocate an Impl in the nsAttrAndChildArray.  The size of the Impl is 8 bytes plus 1 word plus 2 words per attr plus 1 word per child.  In our case that's 48 bytes.  Furthermore, for @style we have to allocate a MiscContainer, which is an enum, then a word, then a 8-byte union.  That's 24 bytes, which jemalloc rounds up to 32.  So that's 80 bytes total. 

Nathan says his mallocSizeOf() for the Impl is 64 bytes, not 48, for some reason.  That gets us up to 96 bytes, still not 144....
Comment 20 Nathan Froyd [:froydnj] 2012-05-31 11:00:46 PDT
GDB transcript:

Breakpoint 4, nsAttrAndChildArray::SizeOfExcludingThis
812	{
(gdb) p mImpl
$213 = (nsAttrAndChildArray::Impl *) 0x7fffbbcc0a80
(gdb) p aMallocSizeOf(mImpl)
$214 = 64
(gdb) p AttrSlotCount()
$215 = 1
(gdb) p *mImpl
$216 = {mAttrAndChildCount = 2049, mBufferSize = 6, mMappedAttrs = 0x0, mBuffer = {0x7fffe536fb00}}
(gdb)
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 11:06:37 PDT
Nathan says that the string stored in the nsAttrValue is about 48 bytes, which would then add up.  The actual string I see in the source is something like "color:#008800;" which is 14 PRUnichars plus null terminator, plus the 4-byte length in the arraybuffer, I would think.  So 15*2+4 = 34, which gets rounded to 48.
Comment 22 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 11:10:52 PDT
Nathan found why 64 instead of 48 too: nsAttrAndChildArray::GrowBy will grow the size of Impl in 8-word increments, for small Impls.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 11:27:44 PDT
OK, so the reason we have poor style context sharing is that the vast majority of the page is a lot of <span>s that all have the same parent and each of which has inline style.  So we don't share their style contexts, and then there is no cousin sharing between their kids either.  So pretty much every node on the page gets a unique style context.

So switching from inline style to classes would save us something like 80 bytes per element (no need for MiscContainer, no need for 48-byte string), plus enable style context sharing and save lots of style memory.

If we assume the page is fixed, our best bang for the buck is trying to share nsIStyleRules for @style with identical text, I think.
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 11:29:33 PDT
And perhaps atomizing the actual style attr values in that situation too, because in this case that would save us those 48 bytes for the string in most cases, I would think.  This is tougher in terms of deciding _when_ to do it.

One interesting option is to move both the nsIStyleRule* and the string into some struct that can then be looked up when we want to share.  Then we'd automagically share the string....
Comment 25 Nathan Froyd [:froydnj] 2012-05-31 11:44:22 PDT
Here's what we get for changing the +/-/hunk <span>s to use class; original page stats in there for comparison purposes:

│  ├──1,384.34 MB (50.31%) -- top(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d, id=12)/active/window(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d)
│  │  ├────763.41 MB (27.74%) -- layout
│  │  │    ├──408.93 MB (14.86%) ── style-contexts
│  │  │    ├──237.74 MB (08.64%) -- frames
│  │  │    │  ├──122.39 MB (04.45%) ── nsInlineFrame
│  │  │    │  ├──114.38 MB (04.16%) ── nsTextFrame
│  │  │    │  └────0.98 MB (00.04%) ++ (20 tiny)
│  │  │    ├───39.42 MB (01.43%) ── pres-contexts
│  │  │    ├───32.80 MB (01.19%) ── line-boxes
│  │  │    ├───30.68 MB (01.11%) ── rule-nodes
│  │  │    └───13.83 MB (00.50%) ++ (2 tiny)
│  │  ├────620.89 MB (22.56%) -- dom [2]
│  │  │    ├──468.68 MB (17.03%) ── element-nodes
│  │  │    ├──152.21 MB (05.53%) ── text-nodes
│  │  │    └────0.00 MB (00.00%) ── comment-nodes
│  │  └──────0.04 MB (00.00%) ── style-sheets
│  ├────858.06 MB (31.18%) -- top(file:///home/froydnj/Desktop/74b2b46fca7d.html, id=17)/active/window(file:///home/froydnj/Desktop/74b2b46fca7d.html)
│  │    ├──587.00 MB (21.33%) -- dom [2]
│  │    │  ├──434.67 MB (15.80%) ── element-nodes
│  │    │  ├──152.33 MB (05.54%) ── text-nodes
│  │    │  └────0.00 MB (00.00%) ── comment-nodes
│  │    ├──271.03 MB (09.85%) -- layout
│  │    │  ├──237.74 MB (08.64%) -- frames
│  │    │  │  ├──122.39 MB (04.45%) ── nsInlineFrame
│  │    │  │  ├──114.38 MB (04.16%) ── nsTextFrame
│  │    │  │  └────0.98 MB (00.04%) ++ (19 tiny)
│  │    │  ├───32.80 MB (01.19%) ── line-boxes
│  │    │  └────0.48 MB (00.02%) -- (5 tiny)
│  │    │       ├──0.25 MB (00.01%) ── pres-contexts
│  │    │       ├──0.15 MB (00.01%) ── style-sets
│  │    │       ├──0.05 MB (00.00%) ── arenas
│  │    │       ├──0.02 MB (00.00%) ── style-contexts
│  │    │       └──0.01 MB (00.00%) ── rule-nodes
│  │    └────0.04 MB (00.00%) ── style-sheets

~500MB less, mostly because we have almost no style-contexts usage, as expected.  dom usage shows the expected effects of saving MiscContainers and strings.  Next big win would require deleting useless <span>s on the page (~87000, so another ~10% memory savings)
Comment 26 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-05-31 13:02:08 PDT
I'd be really interested to know if this is a common pattern on the web. To create lots of elements with identical style attributes. I would sort of expect that to be common and so worth optimizing rather than changing the mxr output.
Comment 27 :Ehsan Akhgari 2012-05-31 13:50:17 PDT
(In reply to Jonas Sicking (:sicking) from comment #26)
> I'd be really interested to know if this is a common pattern on the web. To
> create lots of elements with identical style attributes. I would sort of
> expect that to be common and so worth optimizing rather than changing the
> mxr output.

I would expect that to happen for web pages generated dynamically using tools or server side apps...  At least it's very easy for such apps to fall into this pathological case.
Comment 28 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 14:24:47 PDT
> I would sort of expect that to be common

Yes.  Agreed that we should do something about this.
Comment 29 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2012-05-31 14:27:58 PDT
Interesting question is whether we want to compare strings (advantage: hashable) or compare style rules.
Comment 30 Nicholas Nethercote [:njn] 2012-05-31 17:07:29 PDT
> Yes.  Agreed that we should do something about this.

Can someone file a bug, please :)
Comment 31 Boris Zbarsky [:bz] (still a bit busy) 2012-05-31 17:13:41 PDT
Filed bug 760331.
Comment 32 Ed Morley [:emorley] 2012-07-24 04:35:59 PDT
(In reply to Nathan Froyd (:froydnj) from comment #9)
> Looks like every single context line gets a <span> of its own, even if it
> doesn't need to be colored (for +/- purposes).  The +/- lines also get
> individual style="color:FOO", rather than a common named style (as the line
> numbers, of all things, do); don't know if that makes a difference.  Guess
> the web diffs could use a little HTML optimization.

I optimised the hgweb template slightly in bug 766952 & it reduced usage on the testcase in this bug from 1,132 MB to 784 MB! For about:memory breakdowns before/after, see bug 766952 comment 4 :-)

(Note the hgweb templates are not yet in production, waiting on bug 776874).
Comment 33 Daniel Cater 2012-07-24 06:08:34 PDT
(In reply to Ed Morley [:edmorley] from comment #32)
> (In reply to Nathan Froyd (:froydnj) from comment #9)
> > Looks like every single context line gets a <span> of its own, even if it
> > doesn't need to be colored (for +/- purposes).  The +/- lines also get
> > individual style="color:FOO", rather than a common named style (as the line
> > numbers, of all things, do); don't know if that makes a difference.  Guess
> > the web diffs could use a little HTML optimization.
> 
> I optimised the hgweb template slightly in bug 766952 & it reduced usage on
> the testcase in this bug from 1,132 MB to 784 MB! For about:memory
> breakdowns before/after, see bug 766952 comment 4 :-)
> 
> (Note the hgweb templates are not yet in production, waiting on bug 776874).

Can the original (current) output be stored somewhere as a testcase for this and bug 760331?
Comment 34 Ed Morley [:emorley] 2012-07-24 06:24:32 PDT
Unfortunately the original file is 62MB (!!), which even compressed came to 6.9 mb, over b.m.o's max of 4mb. I'll keep it locally in case anyone needs it in the future (and you could generate it fairly easily by looking at the template diff in the other bug).
Comment 35 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-07-24 06:40:43 PDT
Just put it on people?  It's not perfect (since it's not permanent) but it's better than nothing.
Comment 36 Justin Lebar (not reading bugmail) 2012-07-24 06:43:15 PDT
Created attachment 645277 [details]
Compressed hgweb page, part 1

$ sha1sum tracemonkey-diff.tar 
44a2f94883ffd29614e8c1a313ad7eb50eb53d97  tracemonkey-diff.tar
Comment 37 Justin Lebar (not reading bugmail) 2012-07-24 06:45:23 PDT
Created attachment 645278 [details]
Compressed hgweb page, part 2

Decompress with:

  $ cat file1 file2 | xz -d > tracemonkey.tar
  $ sha1sum tracemonkey.tar
Comment 38 Nicholas Nethercote [:njn] 2012-09-30 16:43:53 PDT
khuey just landed bug 760331 on inbound, which improves things by ~275 MiB on 32-bit builds.  I'd love it if someone on a Windows machine could repeat the measurements from comment 0.  I suspect Firefox won't be the worst now, and we might be in a good enough position to close this bug.
Comment 39 Andrew McCreight [:mccr8] 2012-09-30 16:49:23 PDT
I think Chrome implemented something similar in the last month or so, so for fairness we may want to retest on Canary. ;)
Comment 40 Ed Morley [:emorley] 2012-10-04 04:49:45 PDT
Win32 Nightly (http://hg.mozilla.org/mozilla-central/rev/635fcc11d2b1) on Win7 x64...

With attached version of page (before inline styles were removed from the hgweb templates by bug 766952):
786.10 MB (100.0%) -- explicit
+--687.60 MB (87.47%) -- window-objects
¦  +--681.20 MB (86.66%) -- top(file:///C:/mozilla/Misc/hgweb%20optimisation/before/74b2b46fca7d.htm, id=8)/active/window(file:///C:/mozilla/Misc/hgweb%20optimisation/before/74b2b46fca7d.htm)
¦  ¦  +--491.14 MB (62.48%) -- dom
¦  ¦  ¦  +--344.03 MB (43.76%) -- element-nodes
¦  ¦  ¦  +---86.82 MB (11.04%) -- text-nodes
¦  ¦  ¦  +---60.29 MB (07.67%) -- other [2]
¦  ¦  ¦  +----0.00 MB (00.00%) -- comment-nodes
¦  ¦  +--189.73 MB (24.14%) -- layout
¦  ¦  ¦  +--163.93 MB (20.85%) -- frames
¦  ¦  ¦  ¦  +---81.70 MB (10.39%) -- nsTextFrame
¦  ¦  ¦  ¦  +---81.59 MB (10.38%) -- nsInlineFrame
¦  ¦  ¦  ¦  +----0.64 MB (00.08%) ++ (4 tiny)
¦  ¦  ¦  +---24.60 MB (03.13%) -- line-boxes
¦  ¦  ¦  +----1.20 MB (00.15%) ++ (5 tiny)
¦  ¦  +----0.33 MB (00.04%) ++ (2 tiny)
¦  +----6.40 MB (00.81%) ++ (4 tiny)
+---43.14 MB (05.49%) -- heap-unclassified
+---32.17 MB (04.09%) -- history-links-hashtable
+---16.86 MB (02.14%) -- js-non-window
¦   +--12.54 MB (01.59%) -- compartments
¦   ¦  +--11.28 MB (01.43%) ++ non-window-global
¦   ¦  +---1.26 MB (00.16%) ++ no-global/compartment(atoms)
¦   +---4.32 MB (00.55%) ++ (2 tiny)
+----6.33 MB (00.81%) ++ (10 tiny)

With production version of page (with fixed hgweb templates):
770.58 MB (100.0%) -- explicit
+--644.88 MB (83.69%) -- window-objects
¦  +--638.40 MB (82.85%) -- top(file:///C:/mozilla/Misc/hgweb%20optimisation/after/74b2b46fca7d.htm, id=8)/active/window(file:///C:/mozilla/Misc/hgweb%20optimisation/after/74b2b46fca7d.htm)
¦  ¦  +--455.08 MB (59.06%) -- dom
¦  ¦  ¦  +--307.98 MB (39.97%) -- element-nodes
¦  ¦  ¦  +---86.82 MB (11.27%) -- text-nodes
¦  ¦  ¦  +---60.29 MB (07.82%) -- other [2]
¦  ¦  ¦  +----0.00 MB (00.00%) -- comment-nodes
¦  ¦  +--183.07 MB (23.76%) -- layout
¦  ¦  ¦  +--157.28 MB (20.41%) -- frames
¦  ¦  ¦  ¦  +---81.70 MB (10.60%) -- nsTextFrame
¦  ¦  ¦  ¦  +---74.95 MB (09.73%) -- nsInlineFrame
¦  ¦  ¦  ¦  +----0.64 MB (00.08%) ++ (4 tiny)
¦  ¦  ¦  +---24.60 MB (03.19%) -- line-boxes
¦  ¦  ¦  +----1.18 MB (00.15%) ++ (5 tiny)
¦  ¦  +----0.25 MB (00.03%) ++ (2 tiny)
¦  +----6.48 MB (00.84%) ++ (4 tiny)
+---70.39 MB (09.14%) -- heap-unclassified
+---32.17 MB (04.17%) -- history-links-hashtable
+---16.90 MB (02.19%) -- js-non-window
¦   +--12.57 MB (01.63%) -- compartments
¦   ¦  +--11.31 MB (01.47%) ++ non-window-global
¦   ¦  +---1.26 MB (00.16%) ++ no-global/compartment(atoms)
¦   +---4.33 MB (00.56%) ++ (2 tiny)
+----6.25 MB (00.81%) ++ (10 tiny)

Looks like bug 760331 succeeds in negating the effect of poorly implemented styles :-)
Comment 41 Guilherme Lima 2013-11-30 13:30:51 PST
Chrome has a bug on the test page. It's leaking forever I think.
IE 11 uses 1.1 GB
Nightly peak usage was 1.7 GB close to the ending of the load. After it finished loading the page, stabilized at 1.2 GB

From about:memory (I used my regular profile, with ABP and NoScript)

1,136.72 MB (100.0%) -- explicit
├────706.50 MB (62.15%) -- window-objects
│    ├──675.55 MB (59.43%) -- top(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d, id=34)/active/window(https://hg.mozilla.org/tracemonkey/rev/74b2b46fca7d)
│    │  ├──430.47 MB (37.87%) -- dom
│    │  │  ├──283.48 MB (24.94%) ── element-nodes
│    │  │  ├───86.70 MB (07.63%) ── text-nodes
│    │  │  ├───60.29 MB (05.30%) ── other [2]
│    │  │  └────0.00 MB (00.00%) ++ (2 tiny)
│    │  ├──232.87 MB (20.49%) -- layout
│    │  │  ├──157.28 MB (13.84%) -- frames
│    │  │  │  ├───81.70 MB (07.19%) ── nsTextFrame
│    │  │  │  ├───74.95 MB (06.59%) ── nsInlineFrame
│    │  │  │  └────0.64 MB (00.06%) ++ (4 tiny)
│    │  │  ├───48.37 MB (04.25%) ── pres-contexts
│    │  │  ├───24.60 MB (02.16%) ── line-boxes
│    │  │  └────2.62 MB (00.23%) ++ (4 tiny)
│    │  ├───12.00 MB (01.06%) ── property-tables
│    │  └────0.21 MB (00.02%) ++ (2 tiny)
│    └───30.95 MB (02.72%) ++ (10 tiny)
├────165.92 MB (14.60%) -- heap-overhead
│    ├──161.94 MB (14.25%) ── waste
│    └────3.98 MB (00.35%) ++ (2 tiny)
├─────66.10 MB (05.81%) ── heap-unclassified
├─────65.72 MB (05.78%) -- js-non-window
│     ├──51.92 MB (04.57%) -- zones
│     │  ├──41.85 MB (03.68%) -- zone(0x6a2a400)
│     │  │  ├──26.32 MB (02.32%) ++ (260 tiny)
│     │  │  └──15.53 MB (01.37%) ── unused-gc-things
│     │  └──10.08 MB (00.89%) ++ (9 tiny)
│     ├──12.40 MB (01.09%) ++ runtime
│     └───1.39 MB (00.12%) ++ gc-heap
├─────42.46 MB (03.74%) ── atom-tables
├─────32.17 MB (02.83%) ── history-links-hashtable
├─────26.79 MB (02.36%) ++ (16 tiny)
├─────15.75 MB (01.39%) -- add-ons
│     ├──14.49 MB (01.27%) -- {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
│     │  ├──14.47 MB (01.27%) ++ js-non-window/zones/zone(0x6a2a400)/compartment([System Principal], jar:file:///C:/Users/Guilherme/AppData/Roaming/Mozilla/Firefox/Profiles/iwsrkqyn.default-1382064672733/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!/bootstrap.js (from: resource://gre/modules/XPIProvider.jsm:4162))
│     │  └───0.02 MB (00.00%) ── dom/non-window-global?!/orphan-nodes
│     └───1.26 MB (00.11%) ++ (5 tiny)
└─────15.31 MB (01.35%) -- storage
      ├──13.58 MB (01.19%) ++ sqlite
      └───1.73 MB (00.15%) ++ prefix-set

  917.12 MB ── heap-allocated
1,081.75 MB ── heap-committed
     18.06% ── heap-overhead-ratio
          0 ── host-object-urls
    0.01 MB ── imagelib-surface-cache
    1.04 MB ── js-main-runtime-temporary-peak
          0 ── low-commit-space-events
1,257.48 MB ── private
1,275.56 MB ── resident
1,904.52 MB ── vsize
1,785.88 MB ── vsize-max-contiguous
Comment 42 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2014-02-18 15:06:41 PST
I think we can call this fixed.  Reopen if you disagree.

Note You need to log in before you can comment on or make changes to this bug.