Re: HWA and OMTC on Linux
Thanks Benoit! It is indeed a nice milestone. Congrats are due to nical, Bas, and pretty much all of the graphics team for all the work on the layers refactoring and OMTC. On Wednesday, November 27, 2013 1:25:53 PM UTC+13, Benoit Jacob wrote: Congrats Nick, after all is said and done, this is a very nice milestone to cross! 2013/11/26 Nicholas Cameron nick.r.came...@gmail.com This has finally happened. If it sticks, then after this commit ( https://tbpl.mozilla.org/?tree=Mozilla-Inboundrev=aa0066b3865c) there will be no more main thread OpenGL compositing on any platform. See my blog post ( http://featherweightmusings.blogspot.co.nz/2013/11/no-more-main-thread-opengl-in-firefox.html) for details (basically what I proposed at the beginning of this thread). ___ 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: Reacting more strongly to low-memory situations in Firefox 25
On 11/25/13 11:02 AM, Benjamin Smedberg wrote: == Regression ranges == Some of the issues appear to be recently introduced in Firefox 25. We need to jump on regression ranges ASAP. I could really use help working with users such as those identified at the top of this message to see if there are regression ranges in nightly builds that cause more issues. Benjamin, Please cc me on emails or needinfo me on anything you think I can help with. I may need a quick crash course on debugging memory usage, but glad to learn. -Tracy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: Performance Timeline, User Timing, JSON-LD
I’ve been aware of these proposals. Honestly, there’s not a lot of meat in the performance timeline proposal and one of the editors doesn’t appear to be actively involved anymore. IMO, this is implementation detail for describing the data structures used by a timeline “entry”. I’m not sure how important a cross platform specification is, but would entertain the idea if there were good uses for it. ~ rob On Nov 26, 2013, at 05:56 , Till Schneidereit t...@tillschneidereit.net wrote: I don't know how well (or if at all) the current push for performance devtools is coordinated with these proposals, but it would certainly be worth looking into that. CCing Axel Kratel. On Tue, Nov 26, 2013 at 12:31 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/25/13 7:07 PM, L. David Baron wrote: http://www.w3.org/TR/performance-timeline/ Performance Timeline http://www.w3.org/TR/user-timing/ User Timing Have we had anyone at all review these specs? My past experience with that working group and set of editors doesn't make me sanguine about them producing specs that can actually be implemented without reverse-engineering IE or Chrome If we _haven't_ had someone look at these before, we should do that now. And we probably need someone whose job description includes sanity-checking the stuff this working group produces. -Boris ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: Performance Timeline, User Timing, JSON-LD
I'll take a closer look at it. Will be interesting to see how this fits in with what we're planning, but so far, we didn't plan on taking it into account. - Original Message - From: Rob Campbell rcampb...@mozilla.com To: Till Schneidereit t...@tillschneidereit.net Cc: Boris Zbarsky bzbar...@mit.edu, Axel Kratel akra...@mozilla.com, dev-platform@lists.mozilla.org Sent: Wednesday, November 27, 2013 8:51:32 AM Subject: Re: W3C Proposed Recommendations: Performance Timeline, User Timing, JSON-LD I’ve been aware of these proposals. Honestly, there’s not a lot of meat in the performance timeline proposal and one of the editors doesn’t appear to be actively involved anymore. IMO, this is implementation detail for describing the data structures used by a timeline “entry”. I’m not sure how important a cross platform specification is, but would entertain the idea if there were good uses for it. ~ rob On Nov 26, 2013, at 05:56 , Till Schneidereit t...@tillschneidereit.net wrote: I don't know how well (or if at all) the current push for performance devtools is coordinated with these proposals, but it would certainly be worth looking into that. CCing Axel Kratel. On Tue, Nov 26, 2013 at 12:31 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/25/13 7:07 PM, L. David Baron wrote: http://www.w3.org/TR/performance-timeline/ Performance Timeline http://www.w3.org/TR/user-timing/ User Timing Have we had anyone at all review these specs? My past experience with that working group and set of editors doesn't make me sanguine about them producing specs that can actually be implemented without reverse-engineering IE or Chrome If we _haven't_ had someone look at these before, we should do that now. And we probably need someone whose job description includes sanity-checking the stuff this working group produces. -Boris ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: Performance Timeline, User Timing, JSON-LD
On 11/27/13 11:51 AM, Rob Campbell wrote: IMO, this is implementation detail for describing the data structures used by a timeline “entry” There are specs that expose these entries too, so this is not implementation detail but something we'll need to end up implementing when Facebook and company start using it for telemetry. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On closing old bugs
Lawrence Mandel writes: - Original Message - On 27/11/13 07:36, Gabriele Svelto wrote: I'm always tempted to close the former as duplicates of the actual fix and the latter as WONTFIX so that they won't show up on the following searches but I'm also afraid that closing a bug several years old is akin to thread necromancy [1]. Validly closing a bug is not thread necromancy. With Henri's concerns in mind, feel free to clean up Bugzilla on bug at a time :-) I agree. I don't think that keeping a large backlog of bugs in limbo - where no one is looking at the bugs or has any intention to fix any of them - helps anyone. I don't mean to suggest that we should close out all old bugs but that it is appropriate to close out old bugs that we don't think warrant any attention. Someone else may like to fix the bugs, so please don't close the bugs if it is reasonably likely that they may still be present. To try to be clear, I'm agreeing with Henri and Gerv, but I'm not sure that Lawrence understands. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
Benjamin Smedberg schrieb: On 11/25/13 8:15 PM, Bas Schouten wrote: I'm a little confused, when I force OOM my firefox build on 64-bit windows it -definitely- goes down before it reaches more than 3GB of working set. Am I missing something here? I think so. I did not mention working set at all. I am merely calculating whether users are running win64 or win32, based on whether they have 4G of total VM size (win64) or 2G/3G (win32). Wouldn't a Win64 Nightly get more than 4G VM size? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
A 64-bit build would, but we don't ship those. A win64 machine running a 32-bit program can have 4GB of VM, though. -Jeff - Original Message - From: Robert Kaiser ka...@kairo.at To: dev-platform@lists.mozilla.org Sent: Wednesday, November 27, 2013 4:35:36 PM Subject: Re: Reacting more strongly to low-memory situations in Firefox 25 Benjamin Smedberg schrieb: On 11/25/13 8:15 PM, Bas Schouten wrote: I'm a little confused, when I force OOM my firefox build on 64-bit windows it -definitely- goes down before it reaches more than 3GB of working set. Am I missing something here? I think so. I did not mention working set at all. I am merely calculating whether users are running win64 or win32, based on whether they have 4G of total VM size (win64) or 2G/3G (win32). Wouldn't a Win64 Nightly get more than 4G VM size? KaiRo ___ 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: Reacting more strongly to low-memory situations in Firefox 25
Jeff Gilbert schrieb: A 64-bit build would, but we don't ship those. A win64 machine running a 32-bit program can have 4GB of VM, though. OK, just wanted to make sure. Benjamin looked at 25.0 release data, AFAIK, so that's of course only 32bit, but if we look at Nightly data, I think a significant part of those users is actually on the 64bit Nightlies we provide, so we could get some limited comparison out of that limited data. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 11/21/13, 10:38 PM, Gregory Szorc wrote: On 11/20/13, 9:57 PM, Gregory Szorc wrote: On 11/19/2013 10:08 PM, Gregory Szorc wrote: On 11/18/13, 11:15 PM, Gregory Szorc wrote: Do builds feel like they've gotten faster in the last few weeks^hours? It's because they have. When I did my MacBook Pro comparison [1] with a changeset from Oct 28, build times on my 2013 2.6 GHz MacBook Pro were as follows: Wall 11:13 (673) User 69:55 (4195) Sys6:04 (364) Total 75:59 (4559) I just built the tip of m-c (e4b59fdbc9c2) and times on that same machine are now: Wall 9:23 (563) User 57:38 (3458) Sys4:58 (298) Total 62:36 (3756) And 24 hours later, m-c (4f993fa378eb) is getting faster: Wall 8:47 (527) User 52:41 (3161) Sys4:38 (278) Total 57:19 (3439) And 24 hours later on inbound on Mountain View's November 20'th evening: Wall 8:33 (513) User 49:48 (2988) Sys4:21 (261) Total 54:09 (3249) You people are sick. I go to bed, wake up and my builds have gotten faster (09e33431c543): Wall 8:14 (494) User 48:29 (2909) Sys4:16 (256) Total 52:45 (3165) By disabling WebRTC and ICU, I'm able to achieve: Wall 7:14 (434) User 42:22 (2542) Sys3:30 (210) Total 45:52 (2752) On de5aa094b55f, we're now down to: Wall 7:37 (457) User 45:38 (2738) Sys3:54 (234) Total 49:32 (2972) That's with WebRTC and ICU enabled. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 28/11/2013 06:06, Gregory Szorc wrote: On de5aa094b55f, we're now down to: Wall 7:37 (457) User 45:38 (2738) Sys3:54 (234) Total 49:32 (2972) That's with WebRTC and ICU enabled. Looking at my own stats while building I was wondering if anybody has looked at peak memory consumption with unified sources. Since now we're compiling up to 16 files per compiler instance I would imagine that peak memory consumption has increased, possibly significantly. This could be offset by the fact that most of the files will be sharing headers but I still wonder how much of an impact it has. Gabriele ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 11/28/13, 12:21 PM, Gabriele Svelto wrote: On 28/11/2013 06:06, Gregory Szorc wrote: On de5aa094b55f, we're now down to: Wall 7:37 (457) User 45:38 (2738) Sys3:54 (234) Total 49:32 (2972) That's with WebRTC and ICU enabled. Looking at my own stats while building I was wondering if anybody has looked at peak memory consumption with unified sources. Since now we're compiling up to 16 files per compiler instance I would imagine that peak memory consumption has increased, possibly significantly. This could be offset by the fact that most of the files will be sharing headers but I still wonder how much of an impact it has. Peak RSS likely has increased significantly (hundreds to gigabytes range). However, you can offset this by building in non-unified mode (--disable-unified-compilation) or by decreasing the concurrency of building (make -j). Memory is cheap and getting cheaper. Nobody paid by Mozilla to develop Firefox should have a machine with less than 16 GB. Adding 25%+ to build times to accommodate people on old hardware is not acceptable. We can, however, add build system warnings when inadequate hardware is detected. Bug 914431 is related. Long term, we could explore having the build system adapt to the system's abilities e.g. by dynamically adjusting concurrency based on detection of swapping. Things like this are low in priority compared to making builds faster for the majority of builders. In the interim, patches welcome. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recent build time improvements due to unified sources
On 28/11/2013 08:09, Gregory Szorc wrote: Peak RSS likely has increased significantly (hundreds to gigabytes range). OK, that's what I was curious about. Memory is cheap and getting cheaper. Nobody paid by Mozilla to develop Firefox should have a machine with less than 16 GB. Adding 25%+ to build times to accommodate people on old hardware is not acceptable. My desktop machine's got 32GiB but there's a number of contributors or partners' employees that might not be on such beefy hardware. We often had issues in the past with potential FxOS contributors running into OOM errors while doing their first build. Another common case of OOMs are people building inside a VM. Just yesterday I helped another mozillian figure out why his FxOS build had started to fail. It turned out he was building inside a VM with too many jobs and too little memory dedicated to it. Also I'm not sure how our automated build infrastructure copes with this but I would assume we should have enough memory there (or if we don't the memory/CPU time trade-off is probably worth the improvement in build times). We can, however, add build system warnings when inadequate hardware is detected. [...] In the interim, patches welcome. Since we compute the number of build jobs ourselves (unless the user manually overrides that value) we might enforce some simple rule-of-thumb like no more than 1 build job per GB of memory irrespective of the number of CPUs, or something like that. I'm willing to contribute something along the lines but I'd first like to gather some memory consumption measures with and without unified sources. Gabriele ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
