User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150707051659 Steps to reproduce: How to reproduce: # Start a new Firefox instance (e.g. "firefox -new-instance -ProfileManager") # Install https://addons.mozilla.org/de/firefox/addon/tree-style-tab/ # Install https://addons.mozilla.org/de/firefox/addon/session-manager/ # Store the attached file "2000tabs.session" in the "sessions" directory of the generated Firefox profile. This session represents 2000 tabs, each on URL "about:newtab". # Restart the Firefox instance # Load the "2000tabs" session: ## Go to menu "Tools/Session Manager/Session Manager/Load Session..." ## Select the "2000tabs" session in the "Session Manager" window ## Click on "Append to Current Window" ## Click on "Load" # Use the command "top" to observe the idle CPU load # Wait and observe the idle CPU load Bonus: Try to load 8000 tabs, by repeating the steps above 4 times instead of once. Actual results: The idle CPU load of the "firefox" process hovers around 30% (if you have 2000 empty tabs open and do nothing). Expected results: The idle CPU load of the "firefox" process should remain under 1%.

I think session store can be responsible for most of this (bug 669034 and its dependencies). Could you try the steps at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem to confirm?

reporter, baldauf seems to be gone

With nightly, I was only able to load 1000 blank tabs in reasonable time, 2000 blank tabs take too long. With 1000 blank tabs, I have already around 25% CPU idle load while doing nothing. I have created a performance profile and uploaded it at http://people.mozilla.org/~bgirard/cleopatra/#report=385acbfc6102002a2f9a060593e62d6d14923a99&selection=0,1,138,139,140,141,142,143,144,145,410,257,411 It is clearly visible that the sessionstore is not the culprit for the idle CPU usage, but it is nsJSContext::GarbageCollectNow , hence the garbage collector. It seems that the garbage collector is thrashing.

For this kind of number of tabs, GC should probably be tuned differently than the default settings. What would be recommended for this? Also, is there a way that these numbers could be changed dynamically based on the number of tabs present to respond to the user's different use cases?

In java garbage collectors the generation sizing and growth/shrink increments have a big impact on throughput / GC frequency, which generally would be the limiting factor during startup instead of pause times. But there doesn't seem to be much documentation on the javascript.options.mem.* options, so equivalent tuning is difficult to do for endusers.

(In reply to Xuân Baldauf from comment #3) > With nightly, I was only able to load 1000 blank tabs in reasonable time, > 2000 blank tabs take too long. With 1000 blank tabs, I have already around > 25% CPU idle load while doing nothing. > > I have created a performance profile and uploaded it at > http://people.mozilla.org/~bgirard/cleopatra/ > #report=385acbfc6102002a2f9a060593e62d6d14923a99&selection=0,1,138,139,140, > 141,142,143,144,145,410,257,411 > > It is clearly visible that the sessionstore is not the culprit for the idle > CPU usage, but it is nsJSContext::GarbageCollectNow , hence the garbage > collector. > > It seems that the garbage collector is thrashing. That looks like a non-e10s session. Have you tried e10s? In bug 1194043 comment 3 I've found that it significantly improves startup performance. That has regressed recently, as mentioned in bug 1209689 comment 119 but a nightly build from 2015-11-22 or earlier should show all the performance gains.

(In reply to The 8472 from comment #6) > That looks like a non-e10s session. Have you tried e10s? In bug 1194043 > comment 3 I've found that it significantly improves startup performance. I have now tried e10s on Firefox 42. Trying to load my 8000 tabs session with e10s needed more than 90 minutes, at which time I cancelled the load, compared to about 55 minutes with e10s disabled. The reason seems to be that most of my tabs are unloaded by default, and only loaded on demand anyway.

42 is too old to match my performance numbers, it does not include the fix for bug 1214961. Try with a build from https://archive.mozilla.org/pub/firefox/nightly/2015/11/2015-11-22-03-02-30-mozilla-central/ that includes bug 1214961 and excludes bug 1209689

One has to wonder: How is Firefox going to handle this scalability issue with the intended process-per-tab setup?

I hope there will be a configurable upper bound for the number of processes, i.e. the process-per-tab rule being non-strict.

(In reply to Mark Straver from comment #9) > One has to wonder: How is Firefox going to handle this scalability issue > with the intended process-per-tab setup? One way, is you trade (lose) memory usage for (better) performance. Personally, I've found* e10s in Firefox does a FAR better job at this than does Chrome. As a side benefit, I've also gotten way greater performance JUST from what I perceive as a reduction in gc overhead. *using e10s for almost a year now

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #11) > (In reply to Mark Straver from comment #9) > > One has to wonder: How is Firefox going to handle this scalability issue > > with the intended process-per-tab setup? > > One way, is you trade (lose) memory usage for (better) performance. > Personally, I've found* e10s in Firefox does a FAR better job at this than > does Chrome. > > As a side benefit, I've also gotten way greater performance JUST from what I > perceive as a reduction in gc overhead. > > *using e10s for almost a year now a) that tradeoff only makes sense when you have ram to spare / the overhead is tolerable. With tabs ranging in the hundreds or thousands it becomes far more questionable b) that tradeoff does not *require* a process-per-tab model. You can just distribute tabs among a fixed amount of processes. in fact, you already get some performance benefits with a single child process c) the GC benefits could also be had with a concurrent GC implementation or - at least that's how it works in java-land to some extent - by giving the GC more breathing room, necessitating less frequent GCs, increasing throughput So your reply does not really answer Mark's question.

(In reply to The 8472 from comment #12) > (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment > #11) > > (In reply to Mark Straver from comment #9) > > > One has to wonder: How is Firefox going to handle this scalability issue > > > with the intended process-per-tab setup? > > > > One way, is you trade (lose) memory usage for (better) performance. > > Personally, I've found* e10s in Firefox does a FAR better job at this than > > does Chrome. > > > > As a side benefit, I've also gotten way greater performance JUST from what I > > perceive as a reduction in gc overhead. > > > > *using e10s for almost a year now > > a) that tradeoff only makes sense when you have ram to spare / the overhead > is tolerable. With tabs ranging in the hundreds or thousands it becomes far > more questionable > ... > So your reply does not really answer Mark's question. You are correct, I didn't precisely answer Mark's question. I should have qualified that I was not speaking specifically about single-progress-per-tab, but rather simply, multiple processes in general. But I was also not saying that it would be acceptable to trade *excessive* memory usage to achieve process-per-tab, nor multiple processes. You read that yourself. But for today at least the question about process-per-tab memory usage is rather a moot point - mozilla is currently not implementing it. And having implemented compartment-per-tab, perhaps it never will. But in any event, even if they do the design point is unlikely to be thousands of tabs. > b) that tradeoff does not *require* a process-per-tab model. You can just > distribute tabs among a fixed amount of processes. in fact, you already get > some performance benefits with a single child process Indeed, a single content process, or a few, is a major step forward. And perhaps eventually they will get to some hybrid. Chrome for example has -process-per-site. A useful reference for the current thinking about Firefox is https://www.reddit.com/r/firefox/comments/3fptie/when_will_nightly_receive_per_tab_multiprocess/ > c) the GC benefits could also be had with a concurrent GC implementation or > - at least that's how it works in java-land to some extent - by giving the > GC more breathing room, necessitating less frequent GCs, increasing > throughput Ineed perhaps concurrent GC will wallpaper some of the current significant inefficiencies of gc. But I am suspicious. And, it has made no progress in over a year. They have focused rather on - https://bugzilla.mozilla.org/show_bug.cgi?id=1057530 reduce GC max-pause to help video. - actively simplifying the GC code in general, such as https://bugzilla.mozilla.org/show_bug.cgi?id=1192301 Bring Order to Chaos (in the GC). (Perhaps in preparation for concurrent GC? I don't know, I don't follow it super closely. But one can hope)

Sorry, I didn't intend to derail this bug, just looking ahead from what I know of indicated plans for e10s. Also, taking a step back, why does it have to be within Firefox's design specs to have 8000 open documents? It's not like there is a proper interface present to handle that many concurrent tabs, even if you have it organized in a tree structure. Is this even a valid bug, all in all?

(In reply to Mark Straver from comment #14) > Also, taking a step back, why does it have to be within Firefox's design > specs to have 8000 open documents? It's not like there is a proper interface > present to handle that many concurrent tabs, even if you have it organized > in a tree structure. Indeed > Is this even a valid bug, all in all? Right, 8000, even 2000 is totally excessive except as a benchmark excercie. 500-1000 might be argued to have high end practical application. (I've recently hit 500. But 200-300 is more then norm) So I would suggest the author a) remove TST to eliminate it's contributions* to the overhead b) test both 500 and 1000 tabls using c) 64bit build, because he's likely pushing driving enough memory usage that gc is just spinning it's wheels in a 32bit Firefox *And if TST is a major factor, then a bug should be filed against it.

(In reply to Mark Straver from comment #14) > Sorry, I didn't intend to derail this bug, just looking ahead from what I > know of indicated plans for e10s. > > Also, taking a step back, why does it have to be within Firefox's design > specs to have 8000 open documents? It's not like there is a proper interface > present to handle that many concurrent tabs, even if you have it organized > in a tree structure. > Is this even a valid bug, all in all? 8000 tabs are not the same as 8000 open documents if you take lazy-loaded sessions and hidden tabs into account. From personal experience I know that having better ways to organize tabs (tab groups, TST) simply leads to behavior where tabs are used like bookmarks because the bookmarks <-> tabs dichotomy is seen as a hindrance and keeping everything as a tab is more convenient and provide additional features such as "Switch to tab" (by name or url) from the url bar.

(In reply to The 8472 from comment #16) > 8000 tabs are not the same as 8000 open documents if you take lazy-loaded > sessions and hidden tabs into account. From an interface (and user) perspective as well as a tab management structure perspective, that makes no difference, though. Even so, all tabs still load blank documents and have frame loaders initialized AFAICT; they may not be the final documents but they are documents nonetheless.

From a user perspective lazy-loaded means "not loaded" or at the very least "empty". So obviously the expectation is that 8000 lazy, empty tabs have minimal footprint. You're mixing up user perspective and underlying technological aspects. I know that lazy-loaded still incur the overhead of about:blank documents and frame scripts. But if we're talking interface and user perspective instead of the underlying technical differences then the user would ask "why should an entry in the tab bar that doesn't even load anything take so much more memory than an entry in the bookmarks menu?". And I don't even mind the memory overhead itself that much... to some extent. The GC not scaling well becomes an issue long before the memory consumption bogs down the host system, and I think that's what this issue is about.

> The GC not scaling well becomes an issue long before the memory consumption bogs down the host system, and I think that's what this issue is about. I would agree that is very likely

Clearing the needinfo and closing the bug as wontfix as the 8000 tab usecase is on the far extreme uses of Firefox and is not something that we should be designing the software for.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #20) > Clearing the needinfo and closing the bug as wontfix as the 8000 tab usecase > is on the far extreme uses of Firefox and is not something that we should be > designing the software for. In order to rationally make that decision, you need to reference a specification telling what the design limit shall be. If that specification does not exist, you need to create it. For example, the specification could say > Firefox is designed to support at most 3 windows with at most 4 tabs each on reference machine 'desktop'. > Firefox is designed to support at most 1 window with at most 3 tabs each on reference machine 'mobile'. > ... > Reference machine 'desktop' is an x86-64 device with at least 2 cores where Firefox has exclusive access to 512MB RAM and is allowed to consume 100% of 1 core. > Reference machine 'mobile' is an ARMv7 device where Firefox has exclusive access to 256MB RAM. Then deciding to close the bug as WONTFIX is warranted. Else, closing the bug as WONTFIX is arbitrary, as such method can always be used to hide bad design or bad implementation, because the criterion whether it is a bug to be fixed or not is invented after the fact, and is moving, and not even spelled out explicitly. I believe that using such a criterion should at least make the criterion explicit (in a specification document). I also believe deciding such a specification document should be a community decision to have some legitimacy (and make it transparent that it is a community decision). Else simple disagreement remains (and there _is_ disagreement apparently about what the design limits should be). Making the criterion explicit in a specification is also required to decide whether the bug is present in the specification limit case (e.g. 12 tabs on 'desktop'). Maybe the bug is even present in cases which one party accepts as "designed for"? Who can decide this if that number of tabs is not revealed? So, I ask you to 1. reopen the bug until there is a specification document specifying a maximum number of tabs per window and a maximum number of windows Firefox should be designed for. 2. suggest such a maximum number of tabs and maximum number of windows which you believe is a good value. Given these data, we can then proceed as follows: 1. Is the specification document acceptable? If no, then a specification bug could be filed. Maybe UI people have a very different view on this number than some software engineers accustomed to the existing Mozilla code base. 2. Does the implementation even meet the low maximum number from the specification? If no, then this bug can be reopened. Please also note that from a UI perspective (as The 8472 already hints in comment #18), once we have session restore, unused tabs (=tabs whose content is not displayed) just serve as better transient bookmarks feature. In as sense, opening a new tab means creating a new bookmark, closing a new tab means deleting an existing bookmark, clicking on a link in a tab means replacing the bookmark. Only a small subset of all those bookmarks is used at any point in time. Hence, the footprint of that behavior should be roughly proportional to the number of active views (="actively used bookmarks"), not proportional to the number of all bookmarks. Then switching tabs is just a away of either accessing a cached view, or reloading a view (because it was evicted from the cache before due to RAM or CPU constraints, or not loaded at all in the current session). Hence, a specification could also read: > Firefox is designed to support, on reference machine 'desktop', at most 20 windows with at most 1000 tabs each, where at most 3 tabs per window are active, and the remainder of tabs are unloaded. This goal is definitely reachable with the current garbarge collector infrastructure. Having a better garbage collector (such as the G1 garbarge collector of the Java Virtual Machine) would be also great, but I've already lost hope in that.

I would like to add that FF runs into various scalability issues way before 8000 tabs. I'm fairly pain-tolerant in these matters and find that things get noticable around 200 tabs and fairly bad around 1500, with most of them lazy-loaded. 8000 probably is a "fails catastrophically" threshold where 500 might be "significantly degraded performance". Improving one would also improve the other.

> So, I ask you to > 1. reopen the bug until there is a specification document specifying a maximum number of tabs per window > and a maximum number of windows Firefox should be designed for. > 2. suggest such a maximum number of tabs and maximum number of windows which you believe is a good value. Firefox does not have a set maximum number of tabs per window. The maximum number is based on your machines performance combined with the optimizations that are built in to Firefox. Low powered machines may struggle at 50 tabs per window, whereas high powered machines such as yours may do well at 8000 tabs per window (after startup obviously). We have data that says the following about Firefox 48 Nightly users (selected because we know that Nightly users tend to easily represent our most heavily "power" users): 1. 89% of these users have only one window open during session restore. [1] 2. 8% of these users have two windows open during session restore. 3. 36% of these users have only one tab restored during session restore. [2] 4. 83% of these users have less than 15 tabs restored during session restore. 5. 0.14% of these users have 265 or more tabs restored during session restore. It is imperative that engineers working on the Firefox project spend there time where it is most beneficial to our users. The numbers above back up the reasoning as to why support for 8000 tabs in a window should not be a priority nor a concern. To see the data yourself you can look at the following two links: > [1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-04-25&keys=__none__!__none__!__none__&max_channel_version=nightly%252F48&measure=FX_SESSION_RESTORE_NUMBER_OF_WINDOWS_RESTORED&min_channel_version=nightly%252F47&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-03-07&table=0&trim=1&use_submission_date=0 > [2] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-04-25&keys=__none__!__none__!__none__&max_channel_version=nightly%252F48&measure=FX_SESSION_RESTORE_NUMBER_OF_TABS_RESTORED&min_channel_version=nightly%252F47&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-03-07&table=0&trim=1&use_submission_date=0