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