Funny folks should bring this up - I recently wrote a blog post about this:
http://mikeconley.ca/blog/2015/05/04/electrolysis-and-the-big-tab-spinner-of-doom/ Funny how things cluster. :) I suggest reading that top to bottom before you continue reading this post. ... Welcome back! :D The e10s team is currently only focused on getting things to work with a single content process at this time. We eventually want to work with multiple content processes (as others have pointed out, the exact number to work with is not clear), but we're focused on working with a single process because we believe this is a strictly easier backdrop to develop against. Once we've got single content process nailed down, we can then start exploring multiple content processes. We might revisit that decision as things stabilize, but in the meantime I want to stress something: if you're cranking up dom.ipc.processCount to avoid the spinner, I suspect you are probably wallpapering over the issue, and robbing us of data. We've just landed Telemetry probes to get tab switch and spinner times[1]. If you bump up dom.ipc.processCount to avoid the spinner, we miss out on knowing when you _would_ have seen the spinner. This makes it harder for us to know whether or not things are improving or getting worse. It makes it harder for us to identify patterns about what conditions cause the spinner to appear. We are just starting to get to the point where we're looking at performance, and I think what would be very valuable is for people to set dom.ipc.processCount to 1, and give us profiles for when they see the spinner. Upload the profiles, and paste a link to them in [2]. I will happily look at them or forward them to people smarter than I to look at them. There's a video in my blog post demonstrating how to get and use the profiler, if you've never used it before. Profiling has already been fruitful! Just yesterday, we identified [3] as a pretty brutal bottleneck for tab switching on OS X. So don't just run away from the spinner - help us drive a flaming stake through its heart with profiles. I think that'd be the best course of action on this issue. -Mike [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1156592 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1135719 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1161166 On 05/05/2015 6:53 AM, Ted Mielczarek wrote: > On Tue, May 5, 2015, at 02:53 AM, Leman Bennett (Omega X) wrote: >> On 5/5/2015 12:23 AM, Robert O'Callahan wrote: >>> On Tue, May 5, 2015 at 10:29 AM, Leman Bennett (Omega X) < >>> Redacted.For.Spam@request.contact> wrote: >>> >>>> Inquiring minds would like to know. >>>> >>>> At the moment, e10s tabs is still somewhat slower than non-e10s. Multiple >>>> content processes would go a long way for more responsive navigation and >>>> less stalls on the one content process. That stall spinner is getting a LOT >>>> of hate at the moment. >>>> >>> >>> I don't know, but I've enabled multiple content processes, and I haven't >>> noticed any problems --- and the spinner does seem to be shown a lot less. >>> >>> Rob >>> >> >> The issue I've seen with dom.ipc.processCount beyond one process is that >> they're not dynamic. Those instances will stay open for the entire >> session and not unload themselves after a time which can mean double the >> memory use. >> >> I heard that there was rumor of a plan to limit process count spawn to >> per-domain. But I've not seen offhand of a bug filed for it or anything >> else that relates to achieving more than one content process instance. > > There's a bug filed[1], but every time I've asked about it I've been > told it's not currently on the roadmap. I, too, find that single-process > e10s is worse for responsiveness, which is unfortunate. Last time I > tried to use dom.ipc.processCount > 1 I found that window.open was > broken (and also target=_blank on links) which made actual browsing > difficult, but I haven't tested it recently. > > I also filed a couple of bugs[2][3] about being smarter about multiple > content processes which would make things a bit nicer. > > -Ted > > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=641683 > 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1066789 > 3. https://bugzilla.mozilla.org/show_bug.cgi?id=1066792 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
