เมื่อ วันอังคารที่ 5 พฤษภาคม ค.ศ. 2015 5 นาฬิกา 29 นาที 54 วินาที UTC+7, Leman
Bennett (Omega X) เขียนว่า:
> 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
>
On Wednesday, 6 May 2015 02:26:17 UTC+1, Mike Hommey wrote:
Nuwa, aiui, can somewhat help here, but the possibly best option is
actually to just not have a separate executable and fork() the main
process (I didn't say this was going to be easy)
Not having a separate executable has some
On Tue, May 5, 2015 at 4:34 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
On Wed, May 6, 2015 at 2:12 AM, Bill McCloskey wmcclos...@mozilla.com wrote:
Regarding process-per-core or process-per-domain or whatever, I just want
to point out that responsiveness will improve even beyond
On Tue, May 05, 2015 at 05:10:42PM -0700, Bill McCloskey wrote:
On Tue, May 5, 2015 at 4:34 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
resident-unique (only available on Linux, alas) is probably the most
interesting measurement in this case.
Usually I see resident-unique
On Wed, May 6, 2015 at 2:12 AM, Bill McCloskey wmcclos...@mozilla.com wrote:
Regarding process-per-core or process-per-domain or whatever, I just want
to point out that responsiveness will improve even beyond process-per-core.
You're probably right, but as you increase the number of processes
On Tue, May 5, 2015 at 4:34 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
resident-unique (only available on Linux, alas) is probably the most
interesting measurement in this case.
Usually I see resident-unique pretty consistently about 15-20MB higher than
explicit for content
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
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
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
On 05/05/2015 12:42 AM, Nicholas Nethercote wrote:
On Mon, May 4, 2015 at 11:53 PM, Leman Bennett (Omega X)
Redacted.For.Spam@request.contact wrote:
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
The only issues I'm aware of with dom.ipc.processCount 1 are:
1. The devtools Browser Content Toolbox doesn't work.
2. Some printing related stuff doesn't work.
3. There's a theoretical issue where plugins can hang when processCount 1
and when more than one plugin is running.
The first two
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 processCount1 ship-worthy
instead of resorting to heroics to get processCount=1 ship-worthy?
I
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
On Tue, May 5, 2015 at 12:42 AM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
On Mon, May 4, 2015 at 11:53 PM, Leman Bennett (Omega X)
Redacted.For.Spam@request.contact wrote:
I heard that there was rumor of a plan to limit process count spawn to
per-domain. But I've not seen offhand of
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
On Mon, May 4, 2015 at 11:53 PM, Leman Bennett (Omega X)
Redacted.For.Spam@request.contact wrote:
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
On Tue, May 05, 2015 at 11:41:41AM -0400, Mike Conley wrote:
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
On 05/05/15 16:40, Mike Hommey wrote:
Last time I tried e10s, which was a while ago, tab switching did feel
weird with e10s *because* of that lack of the browser lock-up, because
now, the tab strip shows you've switched tabs, but the content is still
from before switching, until the spinner
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
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
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.
21 matches
Mail list logo
