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)

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....

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.

Removing the MemShrink tag because it blocks tracking bug 689769 which also has the MemShrink tag.

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.

A question. How many DOM nodes are on this page?

(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.

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?

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.

> 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.

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.

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.

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.

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)

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.

Nathan found why 64 instead of 48 too: nsAttrAndChildArray::GrowBy will grow the size of Impl in 8-word increments, for small Impls.

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.

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.

> 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 :)

Filed bug 760331.

(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).

(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?

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.

$ sha1sum tracemonkey-diff.tar 44a2f94883ffd29614e8c1a313ad7eb50eb53d97 tracemonkey-diff.tar

Decompress with: $ cat file1 file2 | xz -d > tracemonkey.tar $ sha1sum tracemonkey.tar

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. ;)

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 :-)

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.