Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Investigate upto 50% higher memory usage than competing browsers when viewing large changeset diffs on hg.m.o

RESOLVED FIXED in mozilla18

Status

()

Core
General
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: emorley, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
mozilla18
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-IE] [parity-Opera], URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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

6 years ago
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....
Depends on: 676724
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.

Updated

6 years ago
Whiteboard: [MemShrink] [parity-IE] [parity-Opera] → [MemShrink:P2] [parity-IE] [parity-Opera]
Blocks: 689769
Depends on: 674922
Removing the MemShrink tag because it blocks tracking bug 689769 which also has the MemShrink tag.
Whiteboard: [MemShrink:P2] [parity-IE] [parity-Opera] → [parity-IE] [parity-Opera]
(Reporter)

Comment 4

5 years ago
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)
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

5 years ago
A question.  How many DOM nodes are on this page?
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

5 years ago
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?
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.
Attachment #628581 - Attachment is obsolete: true

Comment 10

5 years ago
> 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.
(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

5 years ago
That's pretty bizarre.  We shouldn't be ending up with 200+ bytes per element!  What's going on there?
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

5 years ago
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.
Apparently many of the anchors have URLs associated with them, and those are rather large; nsStandardUrl::SizeOfIncludingThis is routinely returning ~300 bytes.
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.
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

5 years ago
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

5 years ago
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....
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

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
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....
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)
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.
(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

5 years ago
> I would sort of expect that to be common

Yes.  Agreed that we should do something about this.
Interesting question is whether we want to compare strings (advantage: hashable) or compare style rules.
> Yes.  Agreed that we should do something about this.

Can someone file a bug, please :)

Comment 31

5 years ago
Filed bug 760331.
Depends on: 760331
Depends on: 760831
(Reporter)

Comment 32

5 years ago
(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

5 years ago
(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?
(Reporter)

Comment 34

5 years ago
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).
Just put it on people?  It's not perfect (since it's not permanent) but it's better than nothing.
Created attachment 645277 [details]
Compressed hgweb page, part 1

$ sha1sum tracemonkey-diff.tar 
44a2f94883ffd29614e8c1a313ad7eb50eb53d97  tracemonkey-diff.tar
Created attachment 645278 [details]
Compressed hgweb page, part 2

Decompress with:

  $ cat file1 file2 | xz -d > tracemonkey.tar
  $ sha1sum tracemonkey.tar
Attachment #645277 - Attachment mime type: text/plain → application/octet-stream
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.
I think Chrome implemented something similar in the last month or so, so for fairness we may want to retest on Canary. ;)
(Reporter)

Comment 40

5 years ago
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

4 years ago
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
I think we can call this fixed.  Reopen if you disagree.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
You need to log in before you can comment on or make changes to this bug.