User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140716183446

I measured 1.5MB per tab on start-up ("Don't load tab until selected" is enabled).

Type about:memory in a new tab on start-up and save a memory log and attach it to the bug, please.

I just realized that the memory report contains sensitive information (e.g. window titles), is there an easy way to anonymize it?

(In reply to rd.post from comment #3) > I just realized that the memory report contains sensitive information (e.g. > window titles), is there an easy way to anonymize it? It's JSON, so anything that works on that would probably work. Do realize that things like the URLs / page titles are actually relevant to how much memory is consumed - opening 100 tabs with cnn.com and 100 tabs with about:blank is clearly not going to be equivalent...

lacks details

(In reply to :Gijs Kruitbosch from comment #4) > opening 100 tabs with cnn.com and 100 tabs with > about:blank is clearly not going to be equivalent... This shouldn’t make a difference if the tabs are not loaded, right? I have tested it in a blank profile with >100 tabs (URL=http://example.com) and attached a memory log of it. I saw that there is similarily high memory usage under Windows (Vista, 32 bit) so I assume this problem is present on all platforms.

I'm not sure it's really 1.5MB per tab, we'd want to do a memory report at startup w/o a gajillion tabs vs the submitted memory report to get a better overall picture. Then we could roughly say |overhead_per_tab = <mem_usage_w_tabs> - <mem_usage_w_o_tabs> / <num_tabs>|. A quick look at the memory report indicates the about:blank tabs are using ~160K per (although there may be more overhead that I'm missing): 289.65 MB (100.0%) -- explicit ├──116.67 MB (40.28%) ++ js-non-window ├───75.13 MB (25.94%) -- window-objects │ ├──45.87 MB (15.84%) -- (248 tiny) │ │ ├───2.31 MB (00.80%) ++ top(chrome://browser/content/hiddenWindow.xul, id=1) │ │ ├───2.00 MB (00.69%) ++ top(about:memory, id=758) │ │ ├───1.27 MB (00.44%) ++ top(about:newtab, id=593) │ │ ├───1.07 MB (00.37%) ++ top(about:newtab, id=751) │ │ ├───0.17 MB (00.06%) ++ top(about:blank, id=7) │ │ ├───0.17 MB (00.06%) ++ top(about:blank, id=289) │ │ ├───0.16 MB (00.06%) ++ top(about:blank, id=100) │ │ ├───0.16 MB (00.06%) ++ top(about:blank, id=102) <snip several hundred that are 0.16 MB> │ │ ├───0.16 MB (00.06%) ++ top(about:blank, id=98) │ │ ├───0.15 MB (00.05%) ++ top(about:blank, id=197) │ │ ├───0.15 MB (00.05%) ++ top(about:blank, id=6) │ │ └───0.15 MB (00.05%) ++ top(about:blank, id=757) Heap unclassified is a bit high: ├───43.50 MB (15.02%) ── heap-unclassified

Bug 681201 was about the memory usage of unrestored tabs. During the course of that bug the overhead dropped from over 1 MiB to ~160 KiB per tab, which matches erahm's measurements in comment 8. At the time this was deemed enough of an improvement to close the bug. It's fine to have another bug open, but I mention this as a way of explaining that the low-hanging fruit has mostly been picked here.

Bug 1073700 improved the size of an about:blank tab from 132,928 bytes to 106,088 bytes, by my measurements on Linux64.

Moving this off the untriaged list.

I have found some time to test it with and without tabs. In case you want to try it yourself, you can use [1] to open multiple URLs at once. Here are my results: Explicit Allocations with 403 tabs (mostly URL=https://www.youtube.com/watch?v=CE8UhcyJS0I): 357.20 MB Explicit Allocations with a blank profile: 127.01 MB Firefox 34.0.5 OS X 10.10.1 (14B25) That results in ~0.57 MB per tab, if I didn’t overlooked something. By the way, the Activity Monitor in OS X always reports a much higher memory usage in the "Memory" column (about 550 MB in the first case). I don’t know a lot about how Firefox manages memory, but why can’t the tabs remain completely uninitialized until the user clicks on them? [1] http://www.urlopener.com/

I did some testing to confirm this on linux with a clean profile using the latest code from m-c. Steps: 1) open http://gregor-wagner.com/tmp/mem and run membench until completion 2) open about:blank (this is the page that will be restored) 3) exit firefox 4) open firefox 5) generate memory report after minimizing memory usage: |kill -s 35 <pid_of_firefox>| 6) restore session, let things rest for a few minutes 7) kill -s 35 <pid_of_firefox> The about:memory diff of the reports shows an increase of 117MiB. 117 / 154 pages = ~760KiB / page. Some of that memory is in bin-unused so it's not a perfect comparison but we're clearly using more than 160KiB / restored tab.

Detailed bug report for a similar issue, tested in Nightly. https://bugzilla.mozilla.org/show_bug.cgi?id=1125557

one tab/many tabs memory comparison for Nightly 41 https://bugzilla.mozilla.org/show_bug.cgi?id=1125557#c24

Has this bug been resolved by lazy tabs?

I can do another measurement with the steps in comment 15.

Repeating the previous steps I actually see a reduction in memory use after restoring the tab: > Explicit Allocations > > -9.84 MB (100.0%) -- explicit > ├──-9.44 MB (95.94%) ++ gfx > ├──-0.47 MB (04.77%) ++ window-objects > ├──-1.34 MB (13.63%) ++ js-non-window > ├───0.76 MB (-7.70%) ── heap-unclassified > ├───0.30 MB (-3.05%) ++ heap-overhead > ├──-0.34 MB (03.44%) ++ workers/workers(chrome) > ├───0.29 MB (-2.94%) ── profiler/profiler-state > ├───0.27 MB (-2.77%) ++ images > └───0.13 MB (-1.32%) ++ (9 tiny) I think we can call this resolved.