Closed
Bug 632012
Opened 15 years ago
Closed 14 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)
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
Reporter | ||
Updated•15 years ago
|
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
![]() |
||
Updated•15 years ago
|
Reporter | ||
Comment 3•15 years ago
|
||
Reporter | ||
Comment 4•15 years ago
|
||
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.
Comment 5•15 years ago
|
||
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.
Comment 7•15 years ago
|
||
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.
Comment 8•15 years ago
|
||
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.
Comment 9•14 years ago
|
||
(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)
Comment 10•14 years ago
|
||
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]
Updated•14 years ago
|
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)
Updated•14 years ago
|
Attachment #511133 -
Attachment description: Memory usage for 1,100,300,580,800,1000 tabs → Memory usage for {1, 100, 300, 580, 800, 1000} tabs
Comment 11•14 years ago
|
||
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.
Comment 12•14 years ago
|
||
(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.
![]() |
||
Updated•14 years ago
|
Blocks: mslim-fx5+
![]() |
||
Updated•14 years ago
|
Blocks: mlk-fx4-beta
![]() |
||
Comment 13•14 years ago
|
||
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: 14 years ago
Resolution: --- → INCOMPLETE
Comment 14•14 years ago
|
||
Continued in bug 681201.
You need to log in
before you can comment on or make changes to this bug.
Description
•