Re: Announcing the Content Performance program
Nathan, it looks like the SessionRestore feature that was causing test failures has been removed by Tim in the meantime… Does that mean that the 'possible webcompat issues’ is the only real issue left? If so, I’d suggest to request feedback from :annevk and/ or :dbaron (for example) to get a feel for it, because your work in that bug looks too good to let go! Cheers, Mike. On 29 Jun 2015, at 02:14, Nathan Froyd nfr...@mozilla.com wrote: On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote: BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? If you are referring to bug 715376 (and related), those patches are still in my queue, fully rebased. We only need to decide that it's worth spending a significant amount of time addressing the test failures induced by those patches (see comment 109 in that bug, for instance) and the possible webcompat issues from those patches. -Nathan ___ 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: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 5:14 PM, Nathan Froyd nfr...@mozilla.com wrote: On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote: BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? If you are referring to bug 715376 (and related), those patches are still in my queue, fully rebased. We only need to decide that it's worth spending a significant amount of time addressing the test failures induced by those patches (see comment 109 in that bug, for instance) and the possible webcompat issues from those patches. It is awesome to hear that you have those patches rebased. I really hope we push forward with that. In addition to the potential benefits listed in that bug, the JS debugger currently has a lot of issues where suppressing a page's events doesn't actually suppress everything (Promises, postMessage, XHR, I think a couple others) and so JS can still run while you are paused. Being able to use a debugger/chrome dedicated event queue would nicely solve all these cases in one swoop. See https://bugzilla.mozilla.org/show_bug.cgi?id=1074448 for more. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
I'm a big fan of it working, because I believe that it's a key component to handling correctly slow scripts. Cheers, David On 29/06/15 02:14, Nathan Froyd wrote: If you are referring to bug 715376 (and related), those patches are still in my queue, fully rebased. We only need to decide that it's worth spending a significant amount of time addressing the test failures induced by those patches (see comment 109 in that bug, for instance) and the possible webcompat issues from those patches. -Nathan -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 10:09:04PM +0200, David Rajchenbach-Teller wrote: On 28/06/15 20:39, Randell Jesup wrote: I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration There are other options for background tab effects on foreground, though all have some sort of impact. (For example, you could 'freeze' background tabs more aggressively than we currently do. This may have some impact on functionality - we already limit timeouts, but IIRC we don't turn them off entirely, and other events still occur that we could defer until the tab is touched or ignore - but again, that could cause sites to break or make switching back problematic/annoying. However, I'm out of touch with the exact state of our 'freezing' of background tabs. And there are certainly sites where they'll eat your performance (eventually) unless you block everything. Actually, I was just thinking about introducing a priority-to-60fps mode, activated e.g. while the user is scrolling the foreground tab, or perhaps during animations in the foreground tab. Whenever we are running in priority-to-60fps mode, we can delay up to N milliseconds main thread treatments such as: - garbage-collection/cycle-collection; - dispatching events to background tabs (including timeouts); - Session Restore; - Thumbnail creation; - FHR; - Sync; - db flushes; - copying large batches of data to worker threads; - performance monitoring; - ... BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration There are other options for background tab effects on foreground, though all have some sort of impact. (For example, you could 'freeze' background tabs more aggressively than we currently do. This may have some impact on functionality - we already limit timeouts, but IIRC we don't turn them off entirely, and other events still occur that we could defer until the tab is touched or ignore - but again, that could cause sites to break or make switching back problematic/annoying. However, I'm out of touch with the exact state of our 'freezing' of background tabs. And there are certainly sites where they'll eat your performance (eventually) unless you block everything. Have we ever considered building something like the unload tab addon into the platform or Firefox directly? We have talked about it (BarTab Heavy is another example) and the code that Yoric wrote for measuring per-compartment main-thread CPU-usage in about:performance could be used for this. It's unclear how to prioritize it though because doing 100% reliable heavy tab detection will require non-trivial effort (see issues with slow-addon info bar) and the background tab problem will mostly be mitigated by process-per-tab e10s. The problem with auto-unloaders is that you don't want that for some sites - real context or data can be lost. Yes, you can let users white-list things, but only (some) power users would even realize that this is an option or needed. I think serious care needs to be given when thinking of this as a default (or even as a particularly easy option). I think flagging sites as causing slowdown/etc is a great thing and good first step, which puts the control in the user's hands. A nice fire animation on the tab perhaps? ;-) Seems we used to have those in tinderbox https://addons.mozilla.org/en-US/firefox/addon/unloadtab/ An essential add-on for power users that have many tabs open. Curb your resource usage by unloading tabs that you haven't visited for a while. An unloaded tab is restored back to its original state when you need it again. original state likely doesn't include sites that dynamically modify themselves, which is a lot of sites. -- Randell Jesup, Mozilla Corp remove news for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Mon, Jun 29, 2015 at 06:23:30AM +0900, Mike Hommey wrote: On Sun, Jun 28, 2015 at 10:09:04PM +0200, David Rajchenbach-Teller wrote: On 28/06/15 20:39, Randell Jesup wrote: I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration There are other options for background tab effects on foreground, though all have some sort of impact. (For example, you could 'freeze' background tabs more aggressively than we currently do. This may have some impact on functionality - we already limit timeouts, but IIRC we don't turn them off entirely, and other events still occur that we could defer until the tab is touched or ignore - but again, that could cause sites to break or make switching back problematic/annoying. However, I'm out of touch with the exact state of our 'freezing' of background tabs. And there are certainly sites where they'll eat your performance (eventually) unless you block everything. Actually, I was just thinking about introducing a priority-to-60fps mode, activated e.g. while the user is scrolling the foreground tab, or perhaps during animations in the foreground tab. Whenever we are running in priority-to-60fps mode, we can delay up to N milliseconds main thread treatments such as: - garbage-collection/cycle-collection; - dispatching events to background tabs (including timeouts); - Session Restore; - Thumbnail creation; - FHR; - Sync; - db flushes; - copying large batches of data to worker threads; - performance monitoring; - ... BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? Speaking of threads, do we already fiddle with thread priorities so that the OMTC thread possibly gets more time slices? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote: BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? If you are referring to bug 715376 (and related), those patches are still in my queue, fully rebased. We only need to decide that it's worth spending a significant amount of time addressing the test failures induced by those patches (see comment 109 in that bug, for instance) and the possible webcompat issues from those patches. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 5:14 PM, Nathan Froyd nfr...@mozilla.com wrote: On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote: BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? If you are referring to bug 715376 (and related), those patches are still in my queue, fully rebased. We only need to decide that it's worth spending a significant amount of time addressing the test failures induced by those patches (see comment 109 in that bug, for instance) and the possible webcompat issues from those patches. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform I believe he's referring to supersnappy. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sunday, June 28, 2015 at 4:09:18 PM UTC-4, David Rajchenbach-Teller wrote: Actually, I was just thinking about introducing a priority-to-60fps mode, activated e.g. while the user is scrolling the foreground tab, or perhaps during animations in the foreground tab. Whenever we are running in priority-to-60fps mode, we can delay up to N milliseconds main thread treatments such as: - garbage-collection/cycle-collection; - dispatching events to background tabs (including timeouts); - Session Restore; - Thumbnail creation; - FHR; - Sync; - db flushes; - copying large batches of data to worker threads; - performance monitoring; - ... I asked Avi to work on pausing GC/CC during scrolling in Q3 Q4 2014. I still think it's relevant but process-per-tab will give some of the same benefits ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 7:55 PM, Vladan D vdje...@mozilla.com wrote: I asked Avi to work on pausing GC/CC during scrolling in Q3 Q4 2014. I still think it's relevant but process-per-tab will give some of the same benefits Olli is working on creating some kind of unified scheduler for the giant mess of GC and CC timers we currently have, in bug 1168991. This will make it much easier to pause things during scrolling. Andrew ___ 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: Announcing the Content Performance program
From your blog post: Heavy activity in background tabs badly affects desktop Firefox’s scrolling performance1 (much worse than other browsers — we need E10S) I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. Have we ever considered building something like the unload tab addon into the platform or Firefox directly? I know we do some throttling of timeouts, but perhaps we should also consider this heavier handed approach when there are many tabs open. https://addons.mozilla.org/en-US/firefox/addon/unloadtab/ An essential add-on for power users that have many tabs open. Curb your resource usage by unloading tabs that you haven't visited for a while. An unloaded tab is restored back to its original state when you need it again. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration Have we ever considered building something like the unload tab addon into the platform or Firefox directly? We have talked about it (BarTab Heavy is another example) and the code that Yoric wrote for measuring per-compartment main-thread CPU-usage in about:performance could be used for this. It's unclear how to prioritize it though because doing 100% reliable heavy tab detection will require non-trivial effort (see issues with slow-addon info bar) and the background tab problem will mostly be mitigated by process-per-tab e10s. On Fri, Jun 26, 2015 at 5:12 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: From your blog post: Heavy activity in background tabs badly affects desktop Firefox’s scrolling performance1 (much worse than other browsers — we need E10S) I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. Have we ever considered building something like the unload tab addon into the platform or Firefox directly? I know we do some throttling of timeouts, but perhaps we should also consider this heavier handed approach when there are many tabs open. https://addons.mozilla.org/en-US/firefox/addon/unloadtab/ An essential add-on for power users that have many tabs open. Curb your resource usage by unloading tabs that you haven't visited for a while. An unloaded tab is restored back to its original state when you need it again. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Announcing the Content Performance program
Aaron Klotz, Avi Halachmi and I have been studying Firefox's performance on Android Windows over the last few weeks as part of an effort to evaluate Firefox content performance and find actionable issues. We're analyzing and measuring how well Firefox scrolls pages, loads sites, and navigates between pages. At first, we're focusing on 3 reference sites: Twitter, Facebook, and Yahoo Search. We're trying to find reproducible, meaningful, and common use cases on popular sites which result in noticeable performance problems or where Firefox performs significantly worse than competitors. These use cases will be broken down into tests or profiles, and shared with platform teams for optimization (feeding into Platform's 60fps initiative). This Content Performance project is part of the larger organizational effort to improve Firefox quality. This is the first progress update: https://blog.mozilla.org/vdjeric/2015/06/26/announcing-the-content-performance-program/ I'll try to regularly post about our progress. You can can also track our efforts on our mailing list and IRC channel: Mailing list: https://mail.mozilla.org/listinfo/contentperf IRC channel: #contentperf Project wiki page: https://wiki.mozilla.org/Firefox/Content_Performance_Program ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
