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

Reply via email to