Re: Faster builds, now ; on windows, too.
Mike Hommey wrote: On Tue, Oct 22, 2013 at 10:06:13AM +0100, Neil wrote: David Rajchenbach-Teller wrote: Wouldn't it be interesting to also have a ./mach build frontend that repackages XUL and js code? Does ./mach build chrome work? make chrome/mach build chrome doesn't do everything that is not code, sadly. I guess it depends on which js code; from the mention of XUL I was assuming anything with a chrome: URL. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
David Rajchenbach-Teller wrote: Wouldn't it be interesting to also have a ./mach build frontend that repackages XUL and js code? Does ./mach build chrome work? (I don't think it's parallelised though.) Hopefully a combination of bug 929147 with bug 921003 will speed it up. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
(On win7, i7 @3.2GHz) Clobber build from 29 mins down to 24, no-op build from some minutes to 16s! \o/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On Tue, Oct 22, 2013 at 10:06:13AM +0100, Neil wrote: David Rajchenbach-Teller wrote: Wouldn't it be interesting to also have a ./mach build frontend that repackages XUL and js code? Does ./mach build chrome work? (I don't think it's parallelised though.) Hopefully a combination of bug 929147 with bug 921003 will speed it up. make chrome/mach build chrome doesn't do everything that is not code, sadly. We will move towards that, though, maybe in another target (chrome is probably not the right name for that). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On Wednesday, October 16, 2013 4:43:03 PM UTC+3, Mike Hommey wrote: ... - Build with: ./mach build After you built once, you can do edit-compile-edit-compile cycles with: ./mach build binaries So what's the difference between |./mach build| and |./mach build binaries|? would such difference exist also after updating mozillabuild with the new mozmake (or the new make)? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On 10/21/2013 9:47 AM, Avi Hal wrote: On Wednesday, October 16, 2013 4:43:03 PM UTC+3, Mike Hommey wrote: ... - Build with: ./mach build After you built once, you can do edit-compile-edit-compile cycles with: ./mach build binaries So what's the difference between |./mach build| and |./mach build binaries|? would such difference exist also after updating mozillabuild with the new mozmake (or the new make)? https://ci.mozilla.org/job/mozilla-central-docs/Build_Documentation/build-targets.html answers the first part. In addition, mozmake should be faster than pymake in almost all circumstances. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
Wouldn't it be interesting to also have a ./mach build frontend that repackages XUL and js code? On 10/21/13 6:53 PM, Gregory Szorc wrote: So what's the difference between |./mach build| and |./mach build binaries|? would such difference exist also after updating mozillabuild with the new mozmake (or the new make)? https://ci.mozilla.org/job/mozilla-central-docs/Build_Documentation/build-targets.html answers the first part. In addition, mozmake should be faster than pymake in almost all circumstances. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On the Q4 goals list. Bug 929147. On 10/21/2013 2:47 PM, David Rajchenbach-Teller wrote: Wouldn't it be interesting to also have a ./mach build frontend that repackages XUL and js code? On 10/21/13 6:53 PM, Gregory Szorc wrote: So what's the difference between |./mach build| and |./mach build binaries|? would such difference exist also after updating mozillabuild with the new mozmake (or the new make)? https://ci.mozilla.org/job/mozilla-central-docs/Build_Documentation/build-targets.html answers the first part. In addition, mozmake should be faster than pymake in almost all circumstances. ___ 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: Faster builds, now ; on windows, too.
I tend to use something like ./mach build browser/base browser/components browser/themes browser/locales browser/devtools (obviously including only the directories where I changed stuff) Which is fast and works. ~ Gijs On 21/10/13 23:47 , David Rajchenbach-Teller wrote: Wouldn't it be interesting to also have a ./mach build frontend that repackages XUL and js code? On 10/21/13 6:53 PM, Gregory Szorc wrote: So what's the difference between |./mach build| and |./mach build binaries|? would such difference exist also after updating mozillabuild with the new mozmake (or the new make)? https://ci.mozilla.org/job/mozilla-central-docs/Build_Documentation/build-targets.html answers the first part. In addition, mozmake should be faster than pymake in almost all circumstances. ___ 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
Faster builds, now ; on windows, too.
Hi, Episode 1 was the You want faster builds, don't you thread. Episode 2 was the Faster builds, now thread. Here comes episode 3. I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. As of current mozilla-inbound, and I'm sure mozilla-central soon, it only takes a few steps: - Download the mozmake binary from http://people.mozilla.org/~mhommey/mozmake.exe and place it in some location in your $PATH. c:\mozilla-build\msys\local\bin is probably good for most people. See bug 927213 if you want to know how it was built. It will eventually be shipped in next release of MozillaBuild. - Add the following to your mozconfig: export MOZ_PSEUDO_DERECURSE=no-pymake (Note this should become the default next week) - Build with: ./mach build After you built once, you can do edit-compile-edit-compile cycles with: ./mach build binaries Enjoy the faster build times. Cheers, Mike PS: mozmake is also being tested on the birch branch, and it is showing promising turnaround times on Windows build slaves (-35 minutes on opt builds, -1 hour on debug builds ; most of which is, surprisingly, is gained on make check, see https://bugzilla.mozilla.org/show_bug.cgi?id=925605#c13 ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
Thanks for putting this together, and thanks to everybody working on making the build faster and thus making us all more productive. This sped up clobber build times on Windows for me by 6 minutes, around 22%, which is great. Some of us can't switch to a *nix based platform in order to get faster builds, so thanks very much. Cheers, Chris P. On 17-Oct-13 2:43 AM, Mike Hommey wrote: Hi, Episode 1 was the You want faster builds, don't you thread. Episode 2 was the Faster builds, now thread. Here comes episode 3. I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. As of current mozilla-inbound, and I'm sure mozilla-central soon, it only takes a few steps: - Download the mozmake binary from http://people.mozilla.org/~mhommey/mozmake.exe and place it in some location in your $PATH. c:\mozilla-build\msys\local\bin is probably good for most people. See bug 927213 if you want to know how it was built. It will eventually be shipped in next release of MozillaBuild. - Add the following to your mozconfig: export MOZ_PSEUDO_DERECURSE=no-pymake (Note this should become the default next week) - Build with: ./mach build After you built once, you can do edit-compile-edit-compile cycles with: ./mach build binaries Enjoy the faster build times. Cheers, Mike PS: mozmake is also being tested on the birch branch, and it is showing promising turnaround times on Windows build slaves (-35 minutes on opt builds, -1 hour on debug builds ; most of which is, surprisingly, is gained on make check, see https://bugzilla.mozilla.org/show_bug.cgi?id=925605#c13 ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey m...@glandium.org wrote: I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. In case you're interested how this happened... AIUI, these improvements are because make 4.0 came out and it actually implements -jN properly on Windows, and with -jN working it's faster than pymake. (Well, almost properly, which is why glandium had to fix some things. Presumably/hopefully his fixes will end up in make 4.01 soon.) Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On Wed, Oct 16, 2013 at 08:09:23PM -0700, Nicholas Nethercote wrote: On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey m...@glandium.org wrote: I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. In case you're interested how this happened... AIUI, these improvements are because make 4.0 came out and it actually implements -jN properly on Windows, and with -jN working it's faster than pymake. (Well, almost properly, which is why glandium had to fix some things. Presumably/hopefully his fixes will end up in make 4.01 soon.) (FYI, FWIW) -jN itself works properly. I just had to patch for unrelated issues, namely: - a typo that makes $(info), $(warning) and $(error) unreliable at best, or crashy at worst. - attempt to execute msys-path programs (e.g. /usr/bin/install) with CreateProcess() (yeah, that doesn't work well) - enable a builtin workaround for sh.exe not working very very well with quotes in a sh -c command. The latter is a #define in config.h that exists for that purpose but is not enabled by default, the former two are submitted upstream. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now.
On 07/10/13 14:11 , Honza Bambas wrote: Is this supposed to work on Windows too? a clobbered build of up to date m-c with export MOZ_PSEUDO_DERECURSE=1 gives me an error during configure phase (./mach build): No: On 10/2/2013 3:17 AM, Mike Hommey wrote: snip Except if you're using pymake, sadly. snip ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now.
I just did a no-op ./mach build binaries on my debug build on a Mac, and it took about 28 seconds. $ time ./mach build binaries 0:01.96 /usr/bin/make -j8 -s binaries 0:12.19 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.22 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.38 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.70 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.09 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.11 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:20.46 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m28.291s user0m8.685s sys 0m4.178s Do you have any plans to bring down the overhead? Do you know where this overhead is coming from? Thanks! Ehsan On 2013-10-01 9:17 PM, Mike Hommey wrote: Hi, If you've read the You want faster builds, don't you thread, you may know that some build improvements have recently landed. I just landed the most important part of it all, and we should now be in a much better place, but, as I'm very cautious, and as this is incremental improvements to an existing complex build system that is hard to improve all at once without some subtle breakages, this is opt-in. It also doesn't work with pymake because of bug 918652. At this point, you probably want to know what it is and how to use it. There is now a new target for incremental C/C++ rebuilds. What this means is, you build once like usual. Then after you do your C/C++ changes, instead of: - mach build or make -C objdir, which takes forever - mach build subdirectory/of/the/changes, which sometimes rebuilds toolkit/library, sometimes not, depending what you're rebuilding. - make -C objdir/subdirectory/of/the/changes make -C objdir/toolkit/library, which may actually not be enough. you can now do: - mach build binaries or - make -C objdir binaries It will rebuild your changes and everything that needs rebuilding because of them. It will also do that quickly. There are a few caveats: - it only handles C/C++ changes, including headers. It doesn't handle js modules, chrome data, etc. - it does *not* handle changes to xpidl, webidl, ipdl. yet. There's a followup for this to happen: bug 921309. - it doesn't handle changes to nss, nspr, icu or ffi. If you do changes there, you still need to run a normal build. - it doesn't work without doing a normal build first. - while it shouldn't break your builds, it might subtly skip what you would expect it to build. If it does, please file a bug or contact me on irc. You can still use the old ways until your issues are fixed. Something else that I landed today is support to skip directories during a normal build when they're not relevant to the build. As always, I'm overcautious and this is opt-in. If you want to opt-in for this (and future experimental improvements), please add export MOZ_PSEUDO_DERECURSE=1 to your mozconfig. Except if you're using pymake, sadly. The more people test those experimental improvements, the quicker they can become the default for everyone. For those interested in the gory details, I'll post some on my blog within the next few days. Mike ___ dev-builds mailing list dev-bui...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now.
8.8s here! ~1.5 is startup and checking the build backend is up to date (lots of stats) ~1.5s is processing install manifests. Rest is make processing. The fact that your machine spent ~20s doing install manifest processing tells me: a) Your directory tree wasn't cached (try running again) b) Your I/O layer is slow (I'm building with an SSD) c) Something else wonky creating slow I/O 0:00.14 /usr/bin/make -j8 binaries 0:00.53 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:00.82 make[1]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.16 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:01.45 make[2]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.56 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.56 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.57 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.68 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.72 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.86 From ./dist/include: Kept 3518 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.10 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.10 /usr/bin/make recurse_binaries On 10/2/13 5:42 PM, Ehsan Akhgari wrote: I just did a no-op ./mach build binaries on my debug build on a Mac, and it took about 28 seconds. $ time ./mach build binaries 0:01.96 /usr/bin/make -j8 -s binaries 0:12.19 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.22 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.38 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.70 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.09 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.11 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:20.46 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m28.291s user0m8.685s sys0m4.178s Do you have any plans to bring down the overhead? Do you know where this overhead is coming from? Thanks! Ehsan On 2013-10-01 9:17 PM, Mike Hommey wrote: Hi, If you've read the You want faster builds, don't you thread, you may know that some build improvements have recently landed. I just landed the most important part of it all, and we should now be in a much better place, but, as I'm very cautious, and as this is incremental improvements to an existing complex build system that is hard to improve all at once without some subtle breakages, this is opt-in. It also doesn't work with pymake because of bug 918652. At this point, you probably want to know what it is and how to use it. There is now a new target for incremental C/C++ rebuilds. What this means is, you build once like usual. Then after you do your C/C++ changes, instead of: - mach build or make -C objdir, which takes forever - mach build subdirectory/of/the/changes, which sometimes rebuilds toolkit/library, sometimes not, depending what you're rebuilding. - make -C objdir/subdirectory/of/the/changes make -C objdir/toolkit/library, which may actually not be enough. you can now do: - mach build binaries or - make -C objdir binaries It will rebuild your changes and everything that needs rebuilding because of them. It will also do that quickly. There are a few caveats: - it only handles C/C++ changes, including headers. It doesn't handle js modules, chrome data, etc. - it does *not* handle changes to xpidl, webidl, ipdl. yet. There's a followup for this to happen: bug 921309. - it doesn't handle changes to nss, nspr, icu or ffi. If you do changes there, you still need to run a normal build. - it doesn't work without doing a normal build first. - while it shouldn't break your builds, it might subtly skip what you would expect it to build. If it does, please file a bug or contact me on irc. You can still use the old ways until your issues are fixed. Something else that I landed today is support to skip directories during a normal build when they're not relevant to the build. As always, I'm overcautious and this is opt-in. If you want to opt-in for this (and future experimental improvements), please add export MOZ_PSEUDO_DERECURSE=1 to your mozconfig. Except if you're using pymake, sadly. The more people test those experimental improvements, the quicker they can become the default for everyone. For those interested in the gory details, I'll post some on my blog within the
Re: Faster builds, now.
this works great for me.. touching network/protocol/http/nsHttpChannel.cpp and rebuilding with mach build binaries runs in 26 seconds compared to 61 with just mach build, and I see the same ~35 second savings when doing it on a total nop build (39 vs 5). awesome. -P On Tue, Oct 1, 2013 at 9:17 PM, Mike Hommey m...@glandium.org wrote: Hi, If you've read the You want faster builds, don't you thread, you may know that some build improvements have recently landed. I just landed the most important part of it all, and we should now be in a much better place, but, as I'm very cautious, and as this is incremental improvements to an existing complex build system that is hard to improve all at once without some subtle breakages, this is opt-in. It also doesn't work with pymake because of bug 918652. At this point, you probably want to know what it is and how to use it. There is now a new target for incremental C/C++ rebuilds. What this means is, you build once like usual. Then after you do your C/C++ changes, instead of: - mach build or make -C objdir, which takes forever - mach build subdirectory/of/the/changes, which sometimes rebuilds toolkit/library, sometimes not, depending what you're rebuilding. - make -C objdir/subdirectory/of/the/changes make -C objdir/toolkit/library, which may actually not be enough. you can now do: - mach build binaries or - make -C objdir binaries It will rebuild your changes and everything that needs rebuilding because of them. It will also do that quickly. There are a few caveats: - it only handles C/C++ changes, including headers. It doesn't handle js modules, chrome data, etc. - it does *not* handle changes to xpidl, webidl, ipdl. yet. There's a followup for this to happen: bug 921309. - it doesn't handle changes to nss, nspr, icu or ffi. If you do changes there, you still need to run a normal build. - it doesn't work without doing a normal build first. - while it shouldn't break your builds, it might subtly skip what you would expect it to build. If it does, please file a bug or contact me on irc. You can still use the old ways until your issues are fixed. Something else that I landed today is support to skip directories during a normal build when they're not relevant to the build. As always, I'm overcautious and this is opt-in. If you want to opt-in for this (and future experimental improvements), please add export MOZ_PSEUDO_DERECURSE=1 to your mozconfig. Except if you're using pymake, sadly. The more people test those experimental improvements, the quicker they can become the default for everyone. For those interested in the gory details, I'll post some on my blog within the next few days. Mike ___ 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: Faster builds, now.
Hmm, I'm not sure what's going on. I ran it again four times in a row and I got better results, but the timings show that there is a lot fo difference between the slow and fast cases (no idea why) $ time ./mach build binaries 0:00.81 /usr/bin/make -j8 -s binaries 0:03.90 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.90 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.95 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.02 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.13 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.32 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:06.42 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m13.277s user0m9.969s sys 0m2.929s ehsanakhgari sparky ~ moz mozilla-central include $ time ./mach build binaries 0:00.25 /usr/bin/make -j8 -s binaries 0:01.49 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.49 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.50 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.64 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.67 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.89 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.36 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m10.459s user0m11.120s sys 0m1.914s ehsanakhgari sparky ~ moz mozilla-central include $ time ./mach build binaries 0:00.26 /usr/bin/make -j8 -s binaries 0:01.53 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.54 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.54 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.67 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.80 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.93 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:03.37 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m9.334s user0m10.229s sys 0m1.924s ehsanakhgari sparky ~ moz mozilla-central include $ time ./mach build binaries 0:00.18 /usr/bin/make -j8 -s binaries 0:04.53 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.54 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.54 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.65 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.67 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:04.83 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:06.10 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real0m14.923s user0m9.508s sys 0m1.580s On 2013-10-02 12:20 PM, Gregory Szorc wrote: 8.8s here! ~1.5 is startup and checking the build backend is up to date (lots of stats) ~1.5s is processing install manifests. Rest is make processing. The fact that your machine spent ~20s doing install manifest processing tells me: a) Your directory tree wasn't cached (try running again) b) Your I/O layer is slow (I'm building with an SSD) c) Something else wonky creating slow I/O 0:00.14 /usr/bin/make -j8 binaries 0:00.53 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:00.82 make[1]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.16 MOZBUILD_BACKEND_CHECKED= /usr/bin/make -C js/src backend.RecursiveMakeBackend.built 0:01.45 make[2]: `backend.RecursiveMakeBackend.built' is up to date. 0:01.56 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.56 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.57 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.68 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:01.72 From ./dist/bin: Kept 0 existing; Added/updated 0;
Re: Faster builds, now.
On Wed, Oct 02, 2013 at 11:42:45AM -0400, Ehsan Akhgari wrote: I just did a no-op ./mach build binaries on my debug build on a Mac, and it took about 28 seconds. $ time ./mach build binaries 0:01.96 /usr/bin/make -j8 -s binaries 0:12.19 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.22 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.38 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.70 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.09 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.11 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:20.46 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories. Your build was successful! real 0m28.291s user 0m8.685s sys 0m4.178s Do you have any plans to bring down the overhead? Do you know where this overhead is coming from? Try again now that bug 921307 landed. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
