Re: The e10s throbber
On 07/04/2015 23:41, Robert O'Callahan wrote: 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. Is there any advantage in doing this over using the builtin devtools browser toolbox's profiling tools? I thought they used the same APIs and just visualized differently? ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
Yes they are built on the same SPS profiler backend. However, the gecko profiler addon will do things the builtin devtools can't, like open a shell and call `atos` to symbolicate C++ function addresses. See https://bugzilla.mozilla.org/show_bug.cgi?id=1132529 for some context. For the time being, I would recommend using the gecko profiler addon for debugging chrome and platform performance issues. On Wed, Apr 8, 2015 at 1:59 AM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: On 07/04/2015 23:41, Robert O'Callahan wrote: 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. Is there any advantage in doing this over using the builtin devtools browser toolbox's profiling tools? I thought they used the same APIs and just visualized differently? ~ Gijs ___ 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
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: 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
