1328135 - Move unloaded tabs to their own process

Status: RESOLVED INVALID

(Core :: DOM: Content Processes, defect)

Description

[Timvde]

Bug 1209689 moved all unloaded tabs to the parent process. This puts a lot of strain on it and hurts performance in a session with a lot of unloaded tabs in two ways:

- At start-up, it takes over a minute of cpu time on my (not too new) i7 before the UI can be used[1]
- My chrome process uses about 1.5GB RAM on start-up, which also needs to get GC'ed and what-not. This also costs cpu cycles.

Having not-yet-loaded tabs load in a separate content process, can bypass both issues. Moreover, because it is known that this process will *only* contain blank tabs, the memory usage follows a predictable pattern and GC frequency in this process can probably be reduced a lot.

Bug 906076 is probably a better solution still, but it seems to have stalled, and this might be an easier fix in the short term.

[1] This is on my dirty profile. The same session (700+ tabs) on a clean profile still takes over half a minute to load.

Comment 1

[Andrew McCreight [:mccr8]]

There's a fairly high overhead to a content process, and most users don't have many unloaded tabs, so I don't think this is something we'd want to do in general. It would be a neat thing for an addon to be able to do, but that would require some WebExtension API for mapping tabs to processes, which I'm guessing does not exist.

Comment 2

[Timvde]

I agree that this would be pretty useless for users with maybe a dozen unloaded tabs or fewer, which is the big majority. I can understand if you don't think it is worth the overhead. Maybe only do this starting from some number of unloaded tabs (20? 50?), or having an about:config option to enable it?

Otoh, an API would be very interesting and open up the possibility for users to play with different heuristics themselves. Do you think this would be feasible to make?

Comment 3

[Gabor Krizsanits (INACTIVE)]

(In reply to Timvde from comment #2)
> Otoh, an API would be very interesting and open up the possibility for users
> to play with different heuristics themselves. Do you think this would be
> feasible to make?

I don't know if there is a bug for this, but I'm sure that we want to expose an API for add-ons to play with the process choosing strategy for new tabs (currently it just picks one randomly). And we probably want to do this sooner than later (of course we need to have multiple content processes first to choose from).

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

How many unloaded tabs did you have for 1.5GB of memory in comment 0?  Maybe we could just make each unloaded tab more lighter with less impact.  They really should just be placeholders.

I wonder if what you are really seeing is a large session restore json blob.  I've noticed we tend to keep those in memory unfortunately.

Comment 5

[Andrew McCreight [:mccr8]]

(In reply to Ben Kelly [:bkelly] from comment #4)
> Maybe we could just make each unloaded tab more lighter with less impact.
There's already been a few rounds of optimizations for unloaded tabs. As comment 0 mentions, doing something like bug 906076 would avoid having to create about:blank or whatever stuff we do.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

A memory report might be useful.

Comment 7

[Timvde]

The amount of memory used, isn't really a big problem. I have a session running of more than 750 tabs with 25 active add-ons. I don't see 1.5GB as unreasonably high memory usage (given that a linkedBrowser object is created for each of them). If you want, I can give you a memory report, but I don't think anything interesting will be in it.

The only problem for me here, is the impact this has on the UI. I can totally live with giving a core to a process for over a minute to initiate these tabs when I start Firefox, it's just a pity that it's the same process that manages the interface, so I can't use Firefox in the meantime.

At the same time, I see visible cpu spikes in the chrome process, and every once in a while, it hangs for a second or so. I suppose (I'm not sure how to actually confirm this) that these are major GCs that unnecessarily go through all these tabs' memory. Having them in a separate process, would 1) avoid having long GC pauses in the chrome process and 2) probably allow to decrease the GC frequency for the unloaded tab process, since its memory should be static as long as none of these tabs get loaded. It would basically be a data holding process that barely consumes any CPU cycles.

Comment 8

[Timvde]

Now bug 1256472 landed (great job, guys! :D), this is definitely INVALID.