It definitely makes sense to start your performance investigation with processCount=1 since that will likely highlight the low-hanging fruit which should be fixed regardless of processCount.
My question is: after a decent period of time picking the low-hanging fruit, if there is still non-trivial spinner time for processCount=1, would the team consider shifting efforts to getting processCount>1 ship-worthy instead of resorting to heroics to get processCount=1 ship-worthy? On Tue, May 5, 2015 at 10:41 AM, Mike Conley <mcon...@mozilla.com> wrote: > >> 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
