Re: mach has landed
On Fri, Sep 28, 2012 at 06:45:24AM -0400, Benoit Jacob wrote: 2012/9/28 Aryeh Gregor a...@aryeh.name: On Thu, Sep 27, 2012 at 6:08 PM, Gregory Szorc g...@mozilla.com wrote: I actually held out on you with the initial landing of mach: there is more advanced tree building code in the pipes, complete with progress indicators. However, getting it reviewed is a challenge because we want the build system integration to be right. When that lands, mach will be smart enough to automatically define make flags optimal for your machine. e.g. -j == # of cores. So, you get optimal/parallel builds with no configuration necessary. This will all be configurable, of course. Is -j equal to number of cores really optimal? I've always been told that it's better to set it to more like twice the number of cores, because some fraction of threads will normally be stalled on I/O and you don't want cores idle. Depending on various factors, this can be offset by other factors like cores competing for limited resources such as CPU cache. On my core i7 with 8 logical cores and 8M cache and a SSD, -j8 is fastest. More generally while building a C++ project (C++ is computationally expensive to compile) you're not very likely to be IO bound, especially with a SSD. A C project might be different. On my core i7, -j12 is fastest. bigger values are marginally slower but they are all faster than -j8. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: try: -p all considered harmful?
On 09/28/12 06:42 AM, Bobby Holley wrote: On that note, it would be nice if trychooser could implement some kind of |-p any| syntax that would select a platform with the fastest turnaround time and lowest load. This would save developers from manually doing such round-robin scheduling between linux, linux64, and macosx64 (which, in my experience, produce the fastest runs). Filed this as https://bugzilla.mozilla.org/show_bug.cgi?id=795289. I can't speak to where it falls in RelEng priorities but it's a great idea. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mach has landed
On 9/28/2012 12:58 PM, Mike Hommey wrote: On Fri, Sep 28, 2012 at 06:45:24AM -0400, Benoit Jacob wrote: 2012/9/28 Aryeh Gregor a...@aryeh.name: On Thu, Sep 27, 2012 at 6:08 PM, Gregory Szorc g...@mozilla.com wrote: I actually held out on you with the initial landing of mach: there is more advanced tree building code in the pipes, complete with progress indicators. However, getting it reviewed is a challenge because we want the build system integration to be right. When that lands, mach will be smart enough to automatically define make flags optimal for your machine. e.g. -j == # of cores. So, you get optimal/parallel builds with no configuration necessary. This will all be configurable, of course. Is -j equal to number of cores really optimal? I've always been told that it's better to set it to more like twice the number of cores, because some fraction of threads will normally be stalled on I/O and you don't want cores idle. Depending on various factors, this can be offset by other factors like cores competing for limited resources such as CPU cache. On my core i7 with 8 logical cores and 8M cache and a SSD, -j8 is fastest. More generally while building a C++ project (C++ is computationally expensive to compile) you're not very likely to be IO bound, especially with a SSD. A C project might be different. On my core i7, -j12 is fastest. bigger values are marginally slower but they are all faster than -j8. Mike Win7 x64 / i7@3.9GHz / 8 cores / 12GB@1600MHz / SSD mirrored, warm clobbered build of debug desktop browser: -j12: 19m00s exactly -j9: 18m45s exactly Using more processes then cores is counter productive. I checked this 2 years ago already when build took just 13 minutes (we grow!!). -hb- ___ 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: mach has landed
On Fri, Sep 28, 2012 at 05:34:09PM +0200, Honza Bambas wrote: On 9/28/2012 12:58 PM, Mike Hommey wrote: On Fri, Sep 28, 2012 at 06:45:24AM -0400, Benoit Jacob wrote: 2012/9/28 Aryeh Gregor a...@aryeh.name: On Thu, Sep 27, 2012 at 6:08 PM, Gregory Szorc g...@mozilla.com wrote: I actually held out on you with the initial landing of mach: there is more advanced tree building code in the pipes, complete with progress indicators. However, getting it reviewed is a challenge because we want the build system integration to be right. When that lands, mach will be smart enough to automatically define make flags optimal for your machine. e.g. -j == # of cores. So, you get optimal/parallel builds with no configuration necessary. This will all be configurable, of course. Is -j equal to number of cores really optimal? I've always been told that it's better to set it to more like twice the number of cores, because some fraction of threads will normally be stalled on I/O and you don't want cores idle. Depending on various factors, this can be offset by other factors like cores competing for limited resources such as CPU cache. On my core i7 with 8 logical cores and 8M cache and a SSD, -j8 is fastest. More generally while building a C++ project (C++ is computationally expensive to compile) you're not very likely to be IO bound, especially with a SSD. A C project might be different. On my core i7, -j12 is fastest. bigger values are marginally slower but they are all faster than -j8. Mike Win7 x64 / i7@3.9GHz / 8 cores / 12GB@1600MHz / SSD mirrored, warm clobbered build of debug desktop browser: -j12: 19m00s exactly -j9: 18m45s exactly Using more processes then cores is counter productive. I checked this 2 years ago already when build took just 13 minutes (we grow!!). Conclusion: YMMV, most likely, depending on OS ; I'm on Linux. IOW, it's better to make it configurable. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mach has landed
On 9/28/2012 8:49 AM, Mike Hommey wrote: On Fri, Sep 28, 2012 at 05:45:00PM +0200, Mike Hommey wrote: On Fri, Sep 28, 2012 at 05:34:09PM +0200, Honza Bambas wrote: On 9/28/2012 12:58 PM, Mike Hommey wrote: On Fri, Sep 28, 2012 at 06:45:24AM -0400, Benoit Jacob wrote: 2012/9/28 Aryeh Gregor a...@aryeh.name: On Thu, Sep 27, 2012 at 6:08 PM, Gregory Szorc g...@mozilla.com wrote: I actually held out on you with the initial landing of mach: there is more advanced tree building code in the pipes, complete with progress indicators. However, getting it reviewed is a challenge because we want the build system integration to be right. When that lands, mach will be smart enough to automatically define make flags optimal for your machine. e.g. -j == # of cores. So, you get optimal/parallel builds with no configuration necessary. This will all be configurable, of course. Is -j equal to number of cores really optimal? I've always been told that it's better to set it to more like twice the number of cores, because some fraction of threads will normally be stalled on I/O and you don't want cores idle. Depending on various factors, this can be offset by other factors like cores competing for limited resources such as CPU cache. On my core i7 with 8 logical cores and 8M cache and a SSD, -j8 is fastest. More generally while building a C++ project (C++ is computationally expensive to compile) you're not very likely to be IO bound, especially with a SSD. A C project might be different. On my core i7, -j12 is fastest. bigger values are marginally slower but they are all faster than -j8. Mike Win7 x64 / i7@3.9GHz / 8 cores / 12GB@1600MHz / SSD mirrored, warm clobbered build of debug desktop browser: -j12: 19m00s exactly -j9: 18m45s exactly Using more processes then cores is counter productive. I checked this 2 years ago already when build took just 13 minutes (we grow!!). Conclusion: YMMV, most likely, depending on OS ; I'm on Linux. IOW, it's better to make it configurable. And on OSX, the same is true http://blog.johnford.org/new-mac-builders-ssds-j-settings/ Well, we can all agree that on 99.9% of multi core machines, -jN1 is faster than the implied -j1 default and that the typical naive first-time builder will see faster build times out of the gate if a somewhat reasonable -jN default is chosen for them. If this reduces complaints of I have an i7 and compiling Firefox took over an hour, OMGWTFBBQ?! then we have won, IMO. Power users continue to have the ability to fine-tune their -jN value at their discretion, of course. Nobody loses. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the best way to keep track of all the window objects in a content window?
Paul Rouget wrote: In the Developer Tools, we often need to get a list of all the windows present in a page. (main window, iframes, iframes in iframes, …). We also need to be notified when a new window is created (createElement(iframe)). The naive way to do it: - recursively go throught the iframes via the DOM - add mutations observers to be notified when an iframe is created Is there a better way to do that? I found what I was looking for: https://developer.mozilla.org/en-US/docs/Observer_Notifications#Documents (Thanks Mossop) -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the best way to keep track of all the window objects in a content window?
On 09/28/12 11:08, Paul Rouget wrote: In the Developer Tools, we often need to get a list of all the windows present in a page. (main window, iframes, iframes in iframes, …). We also need to be notified when a new window is created (createElement(iframe)). The naive way to do it: - recursively go throught the iframes via the DOM There are alternatives to this, using the docshell tree f.e., but it probably isn't much different to just doing that. - add mutations observers to be notified when an iframe is created Register an observer notification to be called when content globals are created: https://developer.mozilla.org/en-US/docs/Observer_Notifications#Documents ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Gfx meeting, Monday 2:30 PM US/Pacific
Hello, The Graphics meeting will take place this Monday at 2:30 PM US/Pacific time. That could be Tuesday in your timezone. Please first add your agenda items there: https://wiki.mozilla.org/Platform/GFX/2012-October-1 * Every Monday at 2:30 PM Pacific Time * +1 650 903 0800 x92 Conf# 99366 * +1 416 848 3114 x92 Conf# 99366 * +1 800 707 2533 (pin 369) Conf# 99366 (toll free, Skype) * Video (Vidyo) link: https://v.mozilla.com/flex.html?roomdirect.htmlkey=vu1FKlkBlT29 * Vidyo room 9366 (if you have LDAP and can log in at https://v.mozilla.com) See you, Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mach has landed
Win7 x64 / i7@3.9GHz / 8 cores / 12GB@1600MHz / SSD mirrored, warm clobbered build of debug desktop browser: -j12: 19m00s exactly -j9: 18m45s exactly Using more processes then cores is counter productive. I checked this 2 years ago already when build took just 13 minutes (we grow!!). Conclusion: YMMV, most likely, depending on OS ; I'm on Linux. IOW, it's better to make it configurable. And on OSX, the same is true http://blog.johnford.org/new-mac-builders-ssds-j-settings/ Mike Quoted from that blog: I did find that it is better to set the -j setting too high than it is to set it too low. -Gary ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: try: -p all considered harmful?
On Friday 2012-09-28 16:34 -0400, Justin Lebar wrote: I think adding |-p any| plus explicit acknowledging that a green -p any build is sufficient testing to push non-platform-specific patches to m-i could have a positive impact on our resource usage without causing devs or sheriffs too much pain. As far as this explicitly acknowledging, I'd note that not long ago I edited https://wiki.mozilla.org/Tree_Rules/Inbound to reflect what I think represented rough consensus from a previous discussion on this topic, by adding the parenthetical in the following item: # Inbound is no replacement for Try. You still need to test your # patches before pushing. (This doesn't mean that you need an # all-platforms try run for every patch. But it does mean that # you should do enough testing so that you rarely cause red or # orange on mozilla-inbound. But breaking it rarely is ok. Never # missing a plane means you're spending too much time in # airports; never breaking the tree means you're running too many # tests before landing.) Probably too wordy, but I didn't see a good way to shorten. I'd be happy for it to be more explicit regarding what you said, but when I wrote it, I didn't feel like it represented our consensus. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Josh Matthews is now a peer of private browsing
Howdy all, Josh Matthews has been helping a lot with the per-window private browsing implementation that we have in the works. Throughout this effort, I believe he has come to learn more about our private browsing implementation than myself, so it's long overdue to announce him as the peer of the private browsing module. Private browsing has code spread across all the tree, and anyone who makes changes to that code can now ask Josh for review as well. Please join me in congratulating Josh on this well deserved new responsibility. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: try: -p all considered harmful?
On 09/28/2012 03:42 AM, Bobby Holley wrote: On that note, it would be nice if trychooser could implement some kind of |-p any| syntax that would select a platform with the fastest turnaround time and lowest load. This would save developers from manually doing such round-robin scheduling between linux, linux64, and macosx64 (which, in my experience, produce the fastest runs). People are also welcome to try my experimental new version of trychooser at https://bitbucket.org/sfink/trychooser. It's sort of a love child of Paul Biggar's trychooser and the crecord hg extension. Ok, maybe one-night-stand child; there's not much code in common at this point. I probably ought to be nice and rename it. It doesn't do anything fundamentally different, but it uses a curses-based interface, and I find it much more convenient to use than the questionnaire version. People comfortable with the j and k keys on their keyboards may agree. If you really like the questionnaire, pass it -q. (I haven't hooked up curses autodetection yet.) Finishing it to the point of being more or less releasable was my sick-day project, so it's a little rough. I intend to make it usable for generating the syntax if you're exclusively a gitter, too. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: try: -p all considered harmful?
On Sep 28, 2012, at 6:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: The point is that the patches that _do_ need to land urgently are blocked on lack of resources because people are wasting too many cycles with unnecesary try pushes. This sounds like a notion of priority might be helpful. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: try: -p all considered harmful?
On Friday 2012-09-28 22:16 -0400, Boris Zbarsky wrote: On 9/28/12 10:03 PM, Seth Fowler wrote: On Sep 28, 2012, at 6:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: The point is that the patches that _do_ need to land urgently are blocked on lack of resources because people are wasting too many cycles with unnecesary try pushes. This sounds like a notion of priority might be helpful. There actually is one. It's just not that easy to set, and not advertised much. I also think encouraging its use could be rather dangerous; given current utilization, if we make it easy to adjust priorities, we could get to a point where getting results from try if you don't bump up priority means you wait until the weekend, or perhaps never get the results. It also means relying on people to judge the relative importance of both their work and their time to that of others. I think some people are likely to consistently overestimate and some to underestimate. I'd also just rather not get into a situation where that's required. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
