>> Is there a more detailed description of what the issues with multiple> >> content processes are that e10s itself doesn't suffer from?
I'm interpreting this as, "What are the problems with multiple content processes that single process does not have, from the user's perspective?" This is mostly unknown, simply because dom.ipc.processCount > 1 is not well tested. Most (if not all) e10s tests test a single content process. As a team, when a bug is filed and we see that it's only reproducible with dom.ipc.processCount > 1, the priority immediately drops, because we're just not focusing on it. So the issues with dom.ipc.processCount are mostly unknown - although a few have been filed: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=processCount&list_id=12230722 >> One of the extremely common cases where I used to get the spinner was> when >> my system was under load (outside of Firefox.) I doubt that we're> going to >> be able to fix anything in our code to prevent showing the> spinner in such >> circumstances. Yes, I experience that too - I often see the spinner when I have many tabs open and I'm doing a build in the background. I think it's worth diving in here and investigating what is occurring in that case. I have my suspicions that https://bugzilla.mozilla.org/show_bug.cgi?id=1161166 is a big culprit on OS X, but have nothing but profiles to back that up. My own experience is that the spinner is far more prevalent in the many-tabs-and-build case on OS X than on other platforms, which makes me suspect that we're just doing something wrong somewhere - with bug 1161166 being my top suspect. > Another such common case would be one> CPU hungry tab. I think this falls more under the domain of UX. With single-process Firefox, the whole browser locks up, and we (usually) show a modal dialog asking the user if they want to stop the script. In other cases, we just jank and fail to draw frames until the process is ready. With a content process, the UI remains responsive, but we get this bigass spinner. That's not an amazing trade-off - it's much uglier and louder, IMO, than the whole browser locking up. The big spinner was just an animation that we tossed in so that it was clear that a frame was not ready (and to avoid just painting random video memory), but I should emphasize that it was never meant to ship. If we ship the current appearance of the spinner to our release population... it would mean that my heels have been ground down to nubs, because I will fight tooth and nail to prevent that from happening. I suspect UX feels the same. So for the case where the content process is being blocked by heavy content, we might need to find better techniques to communicate to the user what's going on and to give them options. I suspect / hope that bug 1106527 will carry that work. Here's what I know: 1) Folks are reporting that they _never_ see the spinner when they crank up dom.ipc.processCount > 1. This is true even when they're doing lots of work in the background, like building. Here's what I suspect: 1) I suspect that given the same group of CPU heavy tabs, single-process Firefox will currently perform better than e10s with a single content process. I suspect we can reach parity here. 2) I suspect that OS X is where most of the pain is, and I suspect bug 1161166 is a big part of it. Here's what I suggest: 1) Wait for Telemetry data to come in to get a better sense of who is being affected and what conditions they are under. Hopefully, the population who have dom.ipc.processCount > 1 are small enough that we have useful data for the dom.ipc.processCount = 1 case. 2) Send me profiles for when you see it. 3) Be patient as we figure out what is slow and iron it out. Realize that we're just starting to look at performance, as we've been focusing on stability and making browser features work up until now. 4) Trust that we're not going to ship The Spinner Experience, because shipping it as-is is beyond ill-advised. :D -Mike On 05/05/2015 10:49 AM, Ehsan Akhgari wrote: > On 2015-05-05 10:30 AM, Mike Conley wrote: >> 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. > > I like roc and some other colleagues have also set the process count > pref to 10 for a while and have not noticed any issues that were not > present with one content process. However, I realize that a few > people's anecdotes cannot be a good enough reason to change what we're > planning to do here. :-) > > Is there a more detailed description of what the issues with multiple > content processes are that e10s itself doesn't suffer from? > >> 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. > > One of the extremely common cases where I used to get the spinner was > when my system was under load (outside of Firefox.) I doubt that we're > going to be able to fix anything in our code to prevent showing the > spinner in such circumstances. Another such common case would be one > CPU hungry tab. > > Are we planning on strategies to mitigate that general issue? It's not > clear to me that replacing the (possibly invisible, or at least only > visible in the UI animations) jank that we have without e10s when > switching tabs with a very visible spinner icon in the middle of the > content area is the right trade-off. Even though I _know_ the reason > why we show the spinner, with my user hat on, I think when switching > tabs, Firefox with 1 content process seems more sluggish than no-e10s, > or rather, the visual effect that you'll get in case we show the spinner > with e10s gives me a more sluggish experience than a few small > animations in the UI stuttering. > > Cheers, > Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
