The e10s throbber
With desktop e10s on there can be a noticeable delay after switching tabs where there is a throbber displayed before the page content. Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
e10s team will probably answer these questions better than I can... Is the duration of this delay measured in telemetry anywhere, I don't think any existing Telemetry probes measure this effect. We have the FX_TAB_* histograms but I doubt they reflect the duration of the tab-switch throbber animation. and do we have criteria for how much delay is acceptable in this case? imho, the minimum requirement for e10s tab delay should be no worse than non-e10s. If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? I don't think there's a comparable tab-switch delay in non-e10s. I have seen this tab-switch animation appear for multiple seconds on e10s, whereas I've never seen a tab-switch that slow on non-e10s. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg benja...@smedbergs.us wrote: With desktop e10s on there can be a noticeable delay after switching tabs where there is a throbber displayed before the page content. When the user switches tabs, we allow the content process 300ms to send layer information to the parent. During that time, we show the previous tab. If no layers are received after 300ms, we show the spinner. Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. The switch is definitely more noticeable in e10s because non-e10s would just jank. A spinner (especially a low-quality animated gif like the one we have) is easier to notice than jank. We've considered a couple options for tab switching in bug 632 that would improved perceived response time. One is to cache the tab's background color and show that. Another is to show some sort of screenshot of the tab, although that probably won't work because it would take too much memory. I think we probably want to use a longer delay than 300ms before we show the spinner. We'd also like to look into why it takes so long to re-create the layer tree when we switch to a tab. Sometimes it's caused by a janky content process, but there may be some layout/gfx improvements we could make too. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
On 2015-04-07 8:48 AM, Benjamin Smedberg wrote: Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? We've discussed adding telemetry probes to measure page painting time so we can properly gauge what the impact is of e10s vs non-e10s. See https://bugzilla.mozilla.org/show_bug.cgi?id=1135719 for the bug tracking page render time issues. In terms of acceptable delay, the current working value is 300ms; as in, we fire off a request, wait up to 300ms, switch the tab if it's ready before 300ms, or show the spinner after 300ms and switch the tab if content isn't ready. We've made a lot of changes to this code in the last two weeks so things should be noticeably better than it was before then. As Bill said, non-e10s would just jank if we waited a noticeable amount of time for a page to render, but I think (based on gut feeling rather than any hard data) that e10s seems to be a little slower to paint than non-e10s. I haven't been able to confirm that or reproduce it reliably though. The spinner is also temporary right now, and we're waiting on UX to provide us with an approved spinner in https://bugzilla.mozilla.org/show_bug.cgi?id=1049551. I don't know if they're ok with the one that's currently there but I wonder if the bug being marked as resolved is making them deprioritise it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
On Tue, Apr 7, 2015 at 5:05 PM, Bill McCloskey wmcclos...@mozilla.com wrote: I think we probably want to use a longer delay than 300ms before we show the spinner. We'd also like to look into why it takes so long to re-create the layer tree when we switch to a tab. Sometimes it's caused by a janky content process, but there may be some layout/gfx improvements we could make too. I've been running with dom.ipc.processCount set to 10 for the last two months or so. Before, I saw the throbber a lot, but with 10 content processes, I can't remember seeing it at all recently. That's probably not saying much about the reasons for seeing it with a single content process, though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
I think we probably want to use a longer delay than 300ms before we show the spinner. We'd also like to look into why it takes so long to re-create the layer tree when we switch to a tab. Sometimes it's caused by a janky content process, but there may be some layout/gfx improvements we could make too. I've been running with dom.ipc.processCount set to 10 for the last two months or so. Before, I saw the throbber a lot, but with 10 content processes, I can't remember seeing it at all recently. That's probably not saying much about the reasons for seeing it with a single content process, though. I have the same experience. (On a side note, glitches aside, the experience with dom.ipc.processCount1 is *incredibly* less janky, something I only fully appreciated after using it for a while and then running normal non-e10s FF. I expect this is also the experience Chrome users have when trying FF.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
On Tue, Apr 7, 2015 at 10:06 AM, George Wright geo...@mozilla.com wrote: We've discussed adding telemetry probes to measure page painting time so we can properly gauge what the impact is of e10s vs non-e10s. See https://bugzilla.mozilla.org/show_bug.cgi?id=1135719 for the bug tracking page render time issues. I started looking into adding probes, and it looks like we don't have very good telemetry even for non-e10s tab switching. We measure the cost of updateCurrentBrowser (in FX_TAB_SWITCH_UPDATE_MS) but that's only a part of tab switching. We also try to measure the total switch time in FX_TAB_SWITCH_TOTAL_MS. However, that only seems to be recorded for basic layers, which almost no one uses anymore. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. I see the spinner far too frequently. e10s tab switching is definitely far worse than non-e10s for me. I can reproduce it fairly consistently, though the STR seem to require loading my normal many-tab session and frequent heavy use, so it's hard to reduce to something easily replicable. How can I usefully debug this? Gavin On Tue, Apr 7, 2015 at 8:05 AM, Bill McCloskey wmcclos...@mozilla.com wrote: On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg benja...@smedbergs.us wrote: With desktop e10s on there can be a noticeable delay after switching tabs where there is a throbber displayed before the page content. When the user switches tabs, we allow the content process 300ms to send layer information to the parent. During that time, we show the previous tab. If no layers are received after 300ms, we show the spinner. Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. The switch is definitely more noticeable in e10s because non-e10s would just jank. A spinner (especially a low-quality animated gif like the one we have) is easier to notice than jank. We've considered a couple options for tab switching in bug 632 that would improved perceived response time. One is to cache the tab's background color and show that. Another is to show some sort of screenshot of the tab, although that probably won't work because it would take too much memory. I think we probably want to use a longer delay than 300ms before we show the spinner. We'd also like to look into why it takes so long to re-create the layer tree when we switch to a tab. Sometimes it's caused by a janky content process, but there may be some layout/gfx improvements we could make too. -Bill ___ 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
Re: Misunderstood the Assigned at bugs! Sorry !!!
OK, to reopen this discussion ... I suggested in Bug 1151371 to activate the status IN_PROGRESS in bmo and use this status for bugs that are in progress (patch in work) and that everybody use the status applied in future only as taken or as in the to-dos-list like the others do. My arguments for this and reasons can be found in the bug. Feedback welcome. https://bugzilla.mozilla.org/show_bug.cgi?id=1151371 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
Counter-intuitively, having multiple content processes may use less memory than taking screenshots per tab. Especially if we use the same COW forking FFOS uses the overhead of a content processes should be very small, certainly less than a high resolution screenshot kept around. Not sure do what degree we can replicate on Windows what we do on FFOS to launch content processes. Why don’t we use more than 1 content process by default right now? Thanks, Andreas On Apr 7, 2015, at 12:50 PM, Ted Mielczarek t...@mielczarek.org wrote: On Tue, Apr 7, 2015, at 11:05 AM, Bill McCloskey wrote: On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg benja...@smedbergs.us wrote: With desktop e10s on there can be a noticeable delay after switching tabs where there is a throbber displayed before the page content. When the user switches tabs, we allow the content process 300ms to send layer information to the parent. During that time, we show the previous tab. If no layers are received after 300ms, we show the spinner. Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. The switch is definitely more noticeable in e10s because non-e10s would just jank. A spinner (especially a low-quality animated gif like the one we have) is easier to notice than jank. We've considered a couple options So, assuming there's content script eating up cycles, right now the e10s case will essentially always be worse than the non-e10s case, right? In the non-e10s case the chrome JS for switching tabs will get hung up and result in jank, but then when it gets to run the repaint should be very fast because the layer tree is in-process. In the e10s case the chrome JS will run, then we wait on IPC for the layer tree which will be held up by the content JS, then we have to transmit the layer tree via IPC, and only then can we paint. Short of doing the layer IPC on a different IPC channel this doesn't seem fixable. Alternately we could focus on running 1 content process as others have noted, since that limits the content script problem to tabs running in the same process as the tab you're switching to. -Ted ___ 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
Re: The e10s throbber
On Tue, Apr 7, 2015, at 11:05 AM, Bill McCloskey wrote: On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg benja...@smedbergs.us wrote: With desktop e10s on there can be a noticeable delay after switching tabs where there is a throbber displayed before the page content. When the user switches tabs, we allow the content process 300ms to send layer information to the parent. During that time, we show the previous tab. If no layers are received after 300ms, we show the spinner. Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. The switch is definitely more noticeable in e10s because non-e10s would just jank. A spinner (especially a low-quality animated gif like the one we have) is easier to notice than jank. We've considered a couple options So, assuming there's content script eating up cycles, right now the e10s case will essentially always be worse than the non-e10s case, right? In the non-e10s case the chrome JS for switching tabs will get hung up and result in jank, but then when it gets to run the repaint should be very fast because the layer tree is in-process. In the e10s case the chrome JS will run, then we wait on IPC for the layer tree which will be held up by the content JS, then we have to transmit the layer tree via IPC, and only then can we paint. Short of doing the layer IPC on a different IPC channel this doesn't seem fixable. Alternately we could focus on running 1 content process as others have noted, since that limits the content script problem to tabs running in the same process as the tab you're switching to. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
On Wed, Apr 8, 2015 at 6:27 AM, Gavin Sharp ga...@gavinsharp.com wrote: We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. I see the spinner far too frequently. e10s tab switching is definitely far worse than non-e10s for me. I can reproduce it fairly consistently, though the STR seem to require loading my normal many-tab session and frequent heavy use, so it's hard to reduce to something easily replicable. How can I usefully debug this? Install the Gecko Profiler extension if you haven't already, and profile your tab switching. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
On 04/07/2015 01:15 PM, Tobias B. Besemer wrote: OK, to reopen this discussion ... I suggested in Bug 1151371 to activate the status IN_PROGRESS in bmo and use this status for bugs that are in progress (patch in work) and that everybody use the status applied in future only as taken or as in the to-dos-list like the others do. My arguments for this and reasons can be found in the bug. People already have inconsistent interpretations of what the bug status field ASSIGNED vs NEW means (and inconsistent levels-of-bothering-to-actually-tweak-the-flag). Adding an additional IN_PROGRESS status will likely just make things more confusing -- particularly given that many people won't bother to set it, either explicitly or accidentally. (Why should they? It's extra process for process's sake, and it'd arguably be a waste of their time.) What is the problem you're trying to solve? I think you're worried about new contributors mistakenly thinking NEW means unassigned? If that's your concern, then (to the extent that's an actual problem) I think it'd be better to focus on surfacing the assignee field, and highlighting tools like Bugs Ahoy which these contributors should be using in the first place. I don't think adding an additional status (which will break existing conventions will be applied inconsistently) is going to help here. ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Misunderstood the Assigned at bugs! Sorry !!!
Daniel, Le 8 avr. 2015 à 06:19, Daniel Holbert dholb...@mozilla.com a écrit : People already have inconsistent interpretations of what the bug status field ASSIGNED vs NEW means (and inconsistent levels-of-bothering-to-actually-tweak-the-flag). (Sorry if it had already been discussed in the past, slap me with a URI with the past archived discussion about it.) Agreed for the ASSIGNED vs NEW is bothering to set manually. That said I never understood, why it was not tied to someone being assigned to the bug. Take this bug should flip automatically this field. Going back to nobody should put it back to NEW. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Nuwa on desktop
On Wed, Apr 8, 2015 at 8:00 AM, andreas@gmail.com wrote: Not sure do what degree we can replicate on Windows what we do on FFOS to launch content processes. The Cygwin people have looked into fork() in Windows a bit. Some links: http://www.cygwin.com/ml/cygwin-developers/2011-04/msg00036.html https://github.com/kaniini/win32-fork/blob/master/fork.c It doesn't look promising. Maybe if would work if we ever get to the point where a content process doesn't need to use any Win32 APIs. We might be able to do something Nuwa-like where Gecko subsystems use an explicit shared data segment which is a copy-on-write view of a file. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Nuwa on desktop
On 04/07/2015 06:06 PM, Robert O'Callahan wrote: On Wed, Apr 8, 2015 at 8:00 AM, andreas@gmail.com wrote: Not sure do what degree we can replicate on Windows what we do on FFOS to launch content processes. The Cygwin people have looked into fork() in Windows a bit. Some links: http://www.cygwin.com/ml/cygwin-developers/2011-04/msg00036.html https://github.com/kaniini/win32-fork/blob/master/fork.c It doesn't look promising. Maybe if would work if we ever get to the point where a content process doesn't need to use any Win32 APIs. Even if you used something like Cygwin's fork(), it wouldn't help you, since their implementation isn't copy-on-write: Currently, the Cygwin fork is a non-copy-on-write implementation similar to what was present in early flavors of UNIX.[1] As far as I know, it's flat-out *impossible* to implement copy-on-write process creation using the Win32 API (and if it's not actually impossible, it's pretty close). The NT API is another story, but unless you want to use Windows Services for UNIX / Interix, you're probably not going to get access to the NT kernel features you'd need to do it. We might be able to do something Nuwa-like where Gecko subsystems use an explicit shared data segment which is a copy-on-write view of a file. I agree. Shared memory (e.g. CreateFileMapping[2]?) seems like the closest thing on Windows, although that's a part of the Win32 API I've never touched. - Jim [1] http://www.cygwin.com/cygwin-ug-net/highlights.html [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa366539%28v=vs.85%29.aspx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
