Closed Bug 632012 Opened 9 years ago Closed 9 years ago

Firefox 4 uses 300% more memory for delayed session restore (comparing Firefox 4 with browser.sessionstore.max_concurrent_tabs=0 against Firefox 3.6 with BarTab)

Categories

(Core :: General, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: kolubinowicki, Unassigned)

References

Details

(Keywords: memory-footprint)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110206 Firefox/4.0b12pre
Build Identifier: 

In Firefox 4.0 there is introduced new feature "Bartab like behaviour (Bug 561149)". 
But problem begins when comparing a built-in feature in Firefox 4.0 beta 10 and 

Firefox 3.6.13 with Bartab extension.

About 300% more memory is used by Firefox 4.0 beta 10 browser than Firefox 3.6.13 with Bartab extension. When restoring set of 580 tabs. 

Reproducible: Always

Steps to Reproduce:
Apply settings to browsers:

Clean install, new profile (started at least twice to install extension and configure)
Disk cache=0MB
All plugins manually disabled 
Memory checked using Windows Task Manager

Extension Session Manager
https://addons.mozilla.org/en-us/firefox/addon/session-manager/
(to restore exact set of tabs)

Restore previous tabs and session at browser startup 
Number of restored tabs: 580 

Specific settings:

Firefox 4.0 beta 10

Entry in about:config
browser.sessionstore.max_concurrent_tabs = 0

Firefox 3.6.13

Bartab Addon
https://addons.mozilla.org/en-us/firefox/addon/bartab/


Actual Results:  
Memory usage after restoring session:

Firefox 4.0 beta 10

Working set / Private Working Set in MB

364 / 331
360 / 328
370 / 338

Firefox 3.6.13

Working set / Private Working Set in MB

124 / 97
123 / 96
124 / 97

Expected Results:  
Less than 300% increase in memory usage between Firefox 4.0 and 3.6

See also bug:

Bug 561149 Startup issue: Delay loading of background tabs (BarTab-like behavior) when restoring session 

Bug 598466 - [META] Increase in per-tab memory usage (2-3x) between Firefox 3.6 and 4.0 beta 6
Depends on: 561149, 598466
Version: unspecified → Trunk
Blocks: 598466
No longer depends on: 598466
Check attachment for detailed memory usage between Minefield (Gecko/20110208 Firefox/4.0b12pre) and Firefox 3.6.13 for 1,100,300,580,800,1000 tabs.
these graphs look pretty scary, so hard blocker until we figure out what's up.
blocking2.0: --- → betaN+
OS: Windows 7 → Windows XP
Whiteboard: [hardblocker]
Oh, someone finally filed this bug. I can confirm it. I have ~1100 tabs in my session and with browser.sessionstore.max_concurrent_tabs = 0 right after browser start about:memory says that Memory mapped/Memory in use is ~600-650 megabytes each. I'm using minefield in 32-bit Windows XP with hardware acceleration disabled. Will provide detailed information with screenshots tomorrow. I noticed this regression since the second half of December, so if someone will be looking for bad c-set you should probably start searching there.
This alone isn't a regression of any sort. The feature of session restore that emulates BarTab works differently. BarTab hacked around the tab and kept state a string or JSON object (I don't remember exactly). When the tab was selected it would use session restore to load the tab. It never set up session history. Session restore still entirely sets up each tab with all of its session history and when the tab is selected it loads the right entry from session history.

Now I'm not sure if session history alone is going to account for the difference in memory consumption. There are probably couple things that session restore can do differently to reduce its memory usage, but I highly doubt it's anything on the order of 300% (bug 588506 is one such thing but it shouldn't account for much memory).

I'm much more interested in the default settings case shown in that graph.
I don't understand the bug (yet). I think the only think we'd block on here is a huge memory increase between stock 3.6.x and stock 4.0. If we remove all mention of bartab and modified settings in about:config, is there a serious regression here?

If so, nnethercote can you look at the memory profiles for the testcases? Unless this is just a recap of bug 598466 in which case we should just dup it.
(In reply to comment #8)
> I don't understand the bug (yet). I think the only think we'd block on here is
> a huge memory increase between stock 3.6.x and stock 4.0. If we remove all
> mention of bartab and modified settings in about:config, is there a serious
> regression here?

Based on the defaults in the graph, it looks like it. I still strongly believe it's not (at least directly) due to sessionstore. After we're done restoring we aren't doing anything differently from 3.6.

> If so, nnethercote can you look at the memory profiles for the testcases?

I'm not sure the test cases will show anything more interesting than a smaller session. It's N tabs loading the same google or wikipedia page. I know other testcases have been looked at (though perhaps not actually loaded via session restore).

> Unless this is just a recap of bug 598466 in which case we should just dup it.

Looks awfully similar and the numbers seem to match up (bit less than 2x increase at default settings)
In that case, I'm going to clear the blocking flags because 598466 has already been well-researched, and we can either dup this bug or make it about the extensions case.
blocking2.0: betaN+ → ---
Whiteboard: [hardblocker]
OS: Windows XP → Windows 7
Summary: Nearly 300% increase in memory usage between Firefox 4.0 and 3.6 after session restore when using Bartab extension (built in feature in Firefox 4.0) → Firefox 4 uses 300% more memory for delayed session restore (comparing Firefox 4 with browser.sessionstore.max_concurrent_tabs=0 against Firefox 3.6 with BarTab)
Attachment #511133 - Attachment description: Memory usage for 1,100,300,580,800,1000 tabs → Memory usage for {1, 100, 300, 580, 800, 1000} tabs
Keywords: footprint
If I understand this correctly this bug is about memory increase when _NOT_ restoring tabs, comparing browser.sessionstore.max_concurrent_tabs = 0 on Firefox 4 with Firefox 3 with BarTab in terms of memory consumption. So it's about unloaded tabs and like bug 598466 about restored ones.
(In reply to comment #11)
> If I understand this correctly this bug is about memory increase when _NOT_
> restoring tabs, comparing browser.sessionstore.max_concurrent_tabs = 0 on
> Firefox 4 with Firefox 3 with BarTab in terms of memory consumption.

My point above is that the comparison is not a fair one. BarTab and max_concurrent_tabs = 0 work differently. Comparing bartab in 3.6 to bartab in 4 (assuming its impl doesn't change) is the only fair comparison to make.

That said, there may still be things we can learn from this comparison.
This report is unlikely to result in any action, because the 3.6-with-BarTab comparison against 4.0b-without-BarTab isn't meaningful.

If any of the commenters still think the memory usage is too high, please feel free to file a new bug with specific details.  Before doing so, it would be worth trying Firefox 5, which has better memory behaviour than Firefox 4 (http://blog.mozilla.com/nnethercote/2011/05/25/firefox-5-has-fewer-leaks-than-firefox-4/).  You can get a beta version of Firefox 5 from http://beta.mozilla.org.  Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Continued in bug 681201.
You need to log in before you can comment on or make changes to this bug.