You want faster builds, don't you?

[Mike Hommey]

Hi everyone,

I'm sure the answer to the question asked in the subject of this thread
opener ranges somewhere between "yes" and "OH YEAH BRING IT TO ME ALREADY".

Our build system, you might know, is full of traps, and hard not to
break in subtle ways. So it is with extreme care that I landed bug
907365 and bug 915648 (on m-i currently), which will bring you improved
build times, but only if you opt in for it. I need volunteers ready to
maybe have their builds broken occasionally, but likely not.

The first reason you need to opt in is that I didn't want to risk
breaking releng builds. The second reason is that while we now do have
a way to push some options by default on developer builds while not
touching releng builds, I didn't want to leave people with broken builds
and no alternative other than doing a releng-like build.

At this point, you might ask, "how do I opt-in?". Here you are. Add the
following to your .mozconfig:

export MOZ_PSEUDO_DERECURSE=1

That's it.

Before jumping ahead and building like crazy, you should know that it
currently doesn't work with pymake because of bug 918652. You can try to
remove the assert as noted in the bug, but your warranty will be void.
As far as my testing goes, pymake still works properly without the
assert.

There are four things the two aforementioned landed bugs do:
- Make the tree traversal less recursive. Instead of doing make -C foo,
and from foo, make -C bar, we now do make -C foo and make -C foo/bar
from top-level. This in itself is kind of boring (but
(un?)surprisingly required a lot of preparation), but opens a lot of
possibilities.
- For the compile and tools steps, do everything in parallel instead of
sequentially. As there are no interdependencies between the things
built in those steps, it's supposed not to break.
- For the export step, do everything in parallel instead of
sequentially. As there *are* interdependencies between the things
built in this step, it's possible it brings up some race conditions.
Some manual dependencies have been added to overcome the known
problems, but if you do get a build failure during make export with
MOZ_PSEUDO_DERECURSE=1 please file a bug and rebuild with
MOZ_PSEUDO_DERECURSE=no-parallel-export, or without
MOZ_PSEUDO_DERECURSE (both need mach configure). The former will
keep the parallel builds on the compile and tools steps.
- Prepare the field for more improvements.

If you have any build failure with MOZ_PSEUDO_DERECURSE=1 or
MOZ_PSEUDO_DERECURSE=no-parallel-export, please file a bug, or ping me
on irc. Fortunately, you can get back to having working builds by just
building without MOZ_PSEUDO_DERECURSE.

When it is demonstrated to be robust, it will be made the default for
non-releng builds (not for windows until bug 918652 is fixed somehow
in-tree).

More to come in the next few days. Stay tuned.

Mike

[Nicholas Nethercote]

On Fri, Sep 20, 2013 at 3:58 PM, Mike Hommey <m...@glandium.org> wrote:
>
> Add the following to your .mozconfig:
>
> export MOZ_PSEUDO_DERECURSE=1
>
> That's it.

I just tried this on my fast new Linux machine.

- A |--enable-tests --enable-debug build| with -j8 improved from
15m48s to 13m30s, a 1.17x improvement.

- A |--enable-test --enable-debug --enable-optimize='-O0'| build with
-j8 went from 12m57s to 11m15s, a 1.15x improvement.

Nice!

Nick

[Mike Hommey]

Try an incremental build, too :)

Mike

[Nicholas Nethercote]

On Fri, Sep 20, 2013 at 11:24 PM, Mike Hommey <m...@glandium.org> wrote:
>
> Try an incremental build, too :)

Some fresh results, with a |--enable-test --enable-debug
--enable-optimize='-O0'| build. (And I forgot to mention that I'm
using clang).

- Clobber build: 12m54s --> 11m16s (1.14x faster)

- Touch-jsapi.h-and-rebuild: 5m52s --> 5m16s (1.11x faster)

- No-change-rebuild: 29s --> 23s (1.26x faster)

Nick

[Gregory Szorc]

I'm actually suprised your clobber builds improved that much: clobber
builds are mostly CPU bound today, with the majority of the CPU cycles
going to C++ compilation. Perhaps it's a recent regression from ICU's
suboptimal building?

Anyway, I wanted to reiterate that from the perspective of the build
system, our hands are mostly tied when it comes to making C++
compilation faster. We can deliver precompiled headers and better
support for using "unified" C++ sources, but that's about it. Faster C++
compilation is mostly in the hands of the people who write and maintain
the C++. The effort to reduce header dependency hell *is* paying off.
Once that winds down, we may want to spin up an effort to "profile" the
compiler to find exactly why our C++ compiles so slowly. It certainly
feels slower than other large C++ projects, such as LLVM/Clang.

I'm also surprised your no-change rebuild was 29s before this patch. I'm
still hovering around ~60s on my i7-2600K under Linux and on my 2011 MBP
pre-patch. This patch descreased my no-op times to ~40s. Perhaps it's
time for me to upgrade to a Haswell.

[Nicholas Nethercote]

I did detailed measurements of my new machine here:
https://blog.mozilla.org/nnethercote/2013/09/12/bleg-for-a-new-machine-2/.
The old machine (an i7-2600) took ~48s.

Haswell chips are pretty nice, in my experience. Using clang instead
of GCC also produces big wins -- the stock Ubuntu 13.04 version of
clang is *much* faster than the stock GCC. Details in the blog post.

Nick

[Robert O'Callahan]

On Sat, Sep 21, 2013 at 12:16 PM, Gregory Szorc <g...@mozilla.com> wrote:

> Anyway, I wanted to reiterate that from the perspective of the build
> system, our hands are mostly tied when it comes to making C++
> compilation faster. We can deliver precompiled headers and better
> support for using "unified" C++ sources, but that's about it.
>

I don't think that's necessarily true on Windows. If we can find a way to
generate Visual Studio projects and use those to build, or do most of the
build, we can probably go a lot faster than using cl command-line
invocations compiling one file per invocation.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w *
*

[Anthony Jones]

On 21/09/13 17:58, Robert O'Callahan wrote:
> I don't think that's necessarily true on Windows. If we can find a way to
> generate Visual Studio projects and use those to build, or do most of the
> build, we can probably go a lot faster than using cl command-line
> invocations compiling one file per invocation.

It would be nice to see multiple files per cl invocation. That would
likely be a significant win for Windows. The performance improvements
are good for Linux but Windows build performance still lags many minutes
behind the Linux.

Anthony

[Gregory Szorc]

Not sure what you mean here. If you use /MP to build multiple files with one cl.exe, you lose out on /showIncludes and dependencies would be busted. If you are talking about merging multiple files and compiling as one source file, that can be done. I recently reviewed a patch to make WebIDL compile this way.

The main contributor to Windows being slower is pymake. Python is generally slower than C. We are constantly finding ways to make pymake faster. This sometimes involves optimizing pymake. This sometimes involves enhancing how make is used. It's easy to favor the latter because it makes all platforms better.

[Mark Hammond]

On 23/09/2013 11:04 AM, Gregory Szorc wrote:
> On Sep 22, 2013, at 16:35, Anthony Jones <ajo...@mozilla.com> wrote:
>
>> On 21/09/13 17:58, Robert O'Callahan wrote:
>>> I don't think that's necessarily true on Windows. If we can find a way to
>>> generate Visual Studio projects and use those to build, or do most of the
>>> build, we can probably go a lot faster than using cl command-line
>>> invocations compiling one file per invocation.
>>
>> It would be nice to see multiple files per cl invocation. That would
>> likely be a significant win for Windows. The performance improvements
>> are good for Linux but Windows build performance still lags many minutes
>> behind the Linux.
>
> Not sure what you mean here.

In my experience, a clobber build on Windows does not fully utilize the
CPU - for most of the build, many cores are simply not being used. It
might technically be "CPU bound", but it's certainly not "CPU efficient".

I suspect Roc was suggesting there might still be opportunities to
increase the parallelism of the build that would offer significant wins
on Windows.

[I also see a clobber build spend > 5 minutes in various configure runs,
which frustrates me every time I see it - so I minimize the shell ;]

Mark

[Brian Smith]

On Sun, Sep 22, 2013 at 6:20 PM, Mark Hammond <mham...@skippinet.com.au>wrote:

> [I also see a clobber build spend > 5 minutes in various configure runs,
> which frustrates me every time I see it - so I minimize the shell ;]
>

Yep, and the amazing thing is that we basically don't even need to run most
of that junk on Windows (or any platform), because the vast majority of
configure output is fixed per platform--especially on Windows.

Example of wasted time: checking whether the C++ compiler can compile by
compiling a source file that we don't even need. How about we assume the
C++ compiler can compile a program and then fail when we compile a real
source file if/when our assumption is wrong?

On Mac and Linux, configure is so fast that it might not be worth
optimizing it. But, on Windows it is excruciatingly slow and it is worth
short-circuiting as much of it as we can.

Cheers,
Brian



>
> Mark
>
> ______________________________**_________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform>
>



--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Gregory Szorc]

On Sep 22, 2013, at 18:20, Mark Hammond <mham...@skippinet.com.au> wrote:

> On 23/09/2013 11:04 AM, Gregory Szorc wrote:
>> On Sep 22, 2013, at 16:35, Anthony Jones <ajo...@mozilla.com> wrote:
>>
>>> On 21/09/13 17:58, Robert O'Callahan wrote:
>>>> I don't think that's necessarily true on Windows. If we can find a way to
>>>> generate Visual Studio projects and use those to build, or do most of the
>>>> build, we can probably go a lot faster than using cl command-line
>>>> invocations compiling one file per invocation.
>>>
>>> It would be nice to see multiple files per cl invocation. That would
>>> likely be a significant win for Windows. The performance improvements
>>> are good for Linux but Windows build performance still lags many minutes
>>> behind the Linux.
>>
>> Not sure what you mean here.
>
> In my experience, a clobber build on Windows does not fully utilize the CPU - for most of the build, many cores are simply not being used. It might technically be "CPU bound", but it's certainly not "CPU efficient".
>
> I suspect Roc was suggesting there might still be opportunities to increase the parallelism of the build that would offer significant wins on Windows.

The patches announced in the first post on this thread offer such a solution. They work with GNU make and pymake and can saturate a 64+ core machine.

>
> [I also see a clobber build spend > 5 minutes in various configure runs, which frustrates me every time I see it - so I minimize the shell ;]

We don't have much love for configure either. However, it's only contributing a few extra minutes to Windows builds compared with 15+ minutes that pymake and make traversal is. I hope you understand why fixing configure isn't at the top of the priority list at the moment.

[Robert O'Callahan]

On Mon, Sep 23, 2013 at 1:04 PM, Gregory Szorc <g...@mozilla.com> wrote:

> On Sep 22, 2013, at 16:35, Anthony Jones <ajo...@mozilla.com> wrote:
>
> > On 21/09/13 17:58, Robert O'Callahan wrote:
> >> I don't think that's necessarily true on Windows. If we can find a way
> to
> >> generate Visual Studio projects and use those to build, or do most of
> the
> >> build, we can probably go a lot faster than using cl command-line
> >> invocations compiling one file per invocation.
> >
> > It would be nice to see multiple files per cl invocation. That would
> > likely be a significant win for Windows. The performance improvements
> > are good for Linux but Windows build performance still lags many minutes
> > behind the Linux.
>

> Not sure what you mean here. If you use /MP to build multiple files with

> one cl.exe, you lose out on /showIncludes and dependencies would be busted.
>

I observe that Visual Studio builds do not spawn one cl process per
translation unit. Knowing how slow Windows is at spawning processes, I
suspect the build would be a lot faster if we used a single cl process to
compile multiple tranlation units.

/MP apparently spawns multiple processes to compile a set of files. That's
kind of the opposite of what we want here.

I see how compiling several files in the same cl invocation would mess up
using /showincludes to track dependencies, making this difficult to fix.
The only possibility I can think of for fixing this is to emit a Visual
Studio project and make the Visual Studio builder responsible for tracking
#include dependencies.

[Mark Hammond]

That's great - however, I was just responding to your comment that
"clobber builds are mostly CPU bound today" and pointing out that,
today, that comment doesn't match my experiences.

>> [I also see a clobber build spend > 5 minutes in various configure
>> runs, which frustrates me every time I see it - so I minimize the
>> shell ;]
>
> We don't have much love for configure either. However, it's only
> contributing a few extra minutes to Windows builds compared with 15+
> minutes that pymake and make traversal is. I hope you understand why
> fixing configure isn't at the top of the priority list at the
> moment.

I understand it isn't at the top of the priority list, but it's still
worth keeping it in perspective - I see ~6 minutes of configure for ~30
mins total build time - 20% is significant in anyone's language.

Cheers,

Mark

[Anthony Jones]

On 23/09/13 16:49, Robert O'Callahan wrote:
> I see how compiling several files in the same cl invocation would mess
> up using /showincludes to track dependencies, making this difficult to
> fix. The only possibility I can think of for fixing this is to emit a
> Visual Studio project and make the Visual Studio builder responsible for
> tracking #include dependencies.

Yes. Difficult.

Lets say you compile 10 files together. If you change any of the header
files for the whole set then you'll need to recompile all of those 10
files. After a full build you can chunk any rebuilds together based on
their dependency overlap. The chunking can persist through a clobber.

It really depends on how far we are away from having a Visual Studio
project. If there is something that can be done now then that is better
than waiting for the silver bullet.

Anthony

[Gregory Szorc]

Sorry, having composed that post on my mobile phone, the necessary
asterisks weren't written. There are numerous asterisks when it comes to
build system generalizations because, well, the build system is
complicated. I or any other build peer could explain things in detail in
every email thread complaining about build times, but then we wouldn't
have time to work on the actual build system! I'm optimistic the in-tree
build system documentation I announced a few days ago will eventually
grow this type of documentation so knowledge can be percolated so we
[the build peers] don't feel obligated to brain dump in every email
thread and to every armchair quarterback that shows up.

>>> [I also see a clobber build spend > 5 minutes in various configure
>>> runs, which frustrates me every time I see it - so I minimize the
>>> shell ;]
>>
>> We don't have much love for configure either. However, it's only
>> contributing a few extra minutes to Windows builds compared with 15+
>> minutes that pymake and make traversal is. I hope you understand why
>> fixing configure isn't at the top of the priority list at the
>> moment.
>
> I understand it isn't at the top of the priority list, but it's still
> worth keeping it in perspective - I see ~6 minutes of configure for ~30
> mins total build time - 20% is significant in anyone's language.

~6 minutes for a configure?! I just did a configure from a clobber build
on Windows on my i7-2600K (2+ year old CPU) and it took 2:10. If you are
seeing 6 minutes configure times, you are running an ancient CPU and/or
not an SSD or you have something fubar with your setup (such as running
a VM inside a VM inside a VM Inception style). If your machine *is*
modern and you don't believe you are doing something silly, *please*
file a bug so we can get to the root cause.

[Steve Fink]

On Sun 22 Sep 2013 11:10:15 PM PDT, Gregory Szorc wrote:
> On 9/22/2013 10:05 PM, Mark Hammond wrote:

> Sorry, having composed that post on my mobile phone, the necessary
> asterisks weren't written. There are numerous asterisks when it comes to
> build system generalizations because, well, the build system is
> complicated. I or any other build peer could explain things in detail in
> every email thread complaining about build times, but then we wouldn't
> have time to work on the actual build system! I'm optimistic the in-tree
> build system documentation I announced a few days ago will eventually
> grow this type of documentation so knowledge can be percolated so we
> [the build peers] don't feel obligated to brain dump in every email
> thread and to every armchair quarterback that shows up.
>

>>>> [I also see a clobber build spend > 5 minutes in various configure
>>>> runs, which frustrates me every time I see it - so I minimize the
>>>> shell ;]
>>>
>>> We don't have much love for configure either. However, it's only
>>> contributing a few extra minutes to Windows builds compared with 15+
>>> minutes that pymake and make traversal is. I hope you understand why
>>> fixing configure isn't at the top of the priority list at the
>>> moment.
>>
>> I understand it isn't at the top of the priority list, but it's still
>> worth keeping it in perspective - I see ~6 minutes of configure for ~30
>> mins total build time - 20% is significant in anyone's language.
>

> ~6 minutes for a configure?! I just did a configure from a clobber build
> on Windows on my i7-2600K (2+ year old CPU) and it took 2:10. If you are
> seeing 6 minutes configure times, you are running an ancient CPU and/or
> not an SSD or you have something fubar with your setup (such as running
> a VM inside a VM inside a VM Inception style). If your machine *is*
> modern and you don't believe you are doing something silly, *please*
> file a bug so we can get to the root cause.

My anecdote: about 2 years ago, I did a lot of building on Windows and
tried very hard to use a VM (just one layer -- a Windows 7 Virtualbox
VM inside Fedora x64.) The configure times were excruciating. 6 minutes
sounds about right -- for the top-level configure only. If you add in
the recursive configures (js/src, libffi, I can't remember what else),
it was at least 30 minutes just in configure. This *was* a problem with
the VM, btw -- building directly under Windows 7 was slow during
configure, but not insanely so. The rest of the compile was probably a
little slower inside the VM, but not by much.

While investigating this, I stripped down a configure script to a
miniscule subset of what it really did, and continued to see the order
of magnitude problem inside the VM. (The script didn't do any
compiling, just some sed invocations and maybe some directory
traversals or something.) I have that script and the timings lying
around here somewhere...

[Mark Hammond]

On 23/09/2013 4:10 PM, Gregory Szorc wrote:
> thread and to every armchair quarterback that shows up.

Really? :(

>>>> [I also see a clobber build spend > 5 minutes in various configure
>>>> runs, which frustrates me every time I see it - so I minimize the
>>>> shell ;]
>>>
>>> We don't have much love for configure either. However, it's only
>>> contributing a few extra minutes to Windows builds compared with 15+
>>> minutes that pymake and make traversal is. I hope you understand why
>>> fixing configure isn't at the top of the priority list at the
>>> moment.
>>
>> I understand it isn't at the top of the priority list, but it's still
>> worth keeping it in perspective - I see ~6 minutes of configure for ~30
>> mins total build time - 20% is significant in anyone's language.
>
> ~6 minutes for a configure?! I just did a configure from a clobber build
> on Windows on my i7-2600K (2+ year old CPU) and it took 2:10. If you are
> seeing 6 minutes configure times, you are running an ancient CPU and/or
> not an SSD or you have something fubar with your setup (such as running
> a VM inside a VM inside a VM Inception style). If your machine *is*
> modern and you don't believe you are doing something silly, *please*
> file a bug so we can get to the root cause.

I just did it again, and this time I saw 3 minutes 50 seconds from
"./mach build" until the first non-configure thing happened. It looks
like it ran configure 5 times, so might not be what you mean by "did a
configure".

I can't explain why I regularly saw > 5 minutes previously, but it's
still 10% of the build time. Should I open a bug on that?

[This is all on an i7-3770 CPU with 16GB ram on a spinning RAID disk in
a native (ie, non-VM) windows 7 - but a ~35 min build time implies it's
not particularly slow, right?]

Mark

[Benjamin Smedberg]

On 9/23/2013 1:38 AM, Anthony Jones wrote:
> On 23/09/13 16:49, Robert O'Callahan wrote:
>> I see how compiling several files in the same cl invocation would mess
>> up using /showincludes to track dependencies, making this difficult to
>> fix. The only possibility I can think of for fixing this is to emit a
>> Visual Studio project and make the Visual Studio builder responsible for
>> tracking #include dependencies.
> Yes. Difficult.
>
> Lets say you compile 10 files together. If you change any of the header
> files for the whole set then you'll need to recompile all of those 10
> files.

As long as you have dependency information you don't... you just
recompile the files that need to be rebuilt.

--BDS

[Joshua Cranmer 🐧]

On 9/23/2013 1:10 AM, Gregory Szorc wrote:
> ~6 minutes for a configure?! I just did a configure from a clobber build
> on Windows on my i7-2600K (2+ year old CPU) and it took 2:10. If you are
> seeing 6 minutes configure times, you are running an ancient CPU and/or
> not an SSD or you have something fubar with your setup (such as running
> a VM inside a VM inside a VM Inception style). If your machine *is*
> modern and you don't believe you are doing something silly, *please*
> file a bug so we can get to the root cause.

I definitely recall 5min+ configures on Windows on my main laptop, which
is only two or three years old (no SSD, though). Configures are
*extremely* painful on Windows, though.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Benoit Girard]

On Mon, Sep 23, 2013 at 12:49 AM, Robert O'Callahan <rob...@ocallahan.org>wrote:

> I observe that Visual Studio builds do not spawn one cl process per
> translation unit. Knowing how slow Windows is at spawning processes, I
> suspect the build would be a lot faster if we used a single cl process to
> compile multiple tranlation units.
>
> /MP apparently spawns multiple processes to compile a set of files. That's
> kind of the opposite of what we want here.
>

> I see how compiling several files in the same cl invocation would mess up
> using /showincludes to track dependencies, making this difficult to fix.
> The only possibility I can think of for fixing this is to emit a Visual
> Studio project and make the Visual Studio builder responsible for tracking
> #include dependencies.
>
>

Vlad Ehsan and I did just that. With hacky.mk you can generate a fully
working Visual Studio project which will let you make changes to XUL as
necessary. The problem with MSBuild used by VS is that invokes one process
at a time. So as soon as a group of files requires different flags (and we
aren't even closed to having unified build flag across the tree) they
require a separate invocation of cl.exe by MSBuild and so you end up with
several invocation of cl.exe running serially and your CPU utilization is
far from 100% as the first cl.exe invocation is down to the last 1-2
remaining object file before the next invocation can start. It takes over
an hour to build with VS using hacky.mk. The benefit of specifying a
working VS solution is perfect intellisense. For building it's better to
call a good external build system from your IDE.

[Trevor Saunders]

> >>>>[I also see a clobber build spend > 5 minutes in various configure
> >>>>runs, which frustrates me every time I see it - so I minimize the
> >>>>shell ;]
> >>>
> >>>We don't have much love for configure either. However, it's only
> >>>contributing a few extra minutes to Windows builds compared with 15+
> >>>minutes that pymake and make traversal is. I hope you understand why
> >>>fixing configure isn't at the top of the priority list at the
> >>>moment.
> >>
> >>I understand it isn't at the top of the priority list, but it's still
> >>worth keeping it in perspective - I see ~6 minutes of configure for ~30
> >>mins total build time - 20% is significant in anyone's language.
> >
> >~6 minutes for a configure?! I just did a configure from a clobber build
> >on Windows on my i7-2600K (2+ year old CPU) and it took 2:10. If you are
> >seeing 6 minutes configure times, you are running an ancient CPU and/or
> >not an SSD or you have something fubar with your setup (such as running
> >a VM inside a VM inside a VM Inception style). If your machine *is*
> >modern and you don't believe you are doing something silly, *please*
> >file a bug so we can get to the root cause.
>
> I just did it again, and this time I saw 3 minutes 50 seconds from
> "./mach build" until the first non-configure thing happened. It
> looks like it ran configure 5 times, so might not be what you mean
> by "did a configure".

Well, you could time just running configure by hand.

> I can't explain why I regularly saw > 5 minutes previously, but it's
> still 10% of the build time. Should I open a bug on that?

Jut write a patch to not do even more stuff on windows? it probably
isn't terribly hard assuming there's stuff that will always test true or
false on windows that we haven't stopped running there already. Looking
through configure for such sounds annoying, but not hard.

Trev

>
> [This is all on an i7-3770 CPU with 16GB ram on a spinning RAID disk
> in a native (ie, non-VM) windows 7 - but a ~35 min build time
> implies it's not particularly slow, right?]
>
> Mark
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Neil]

Steve Fink wrote:

>My anecdote: about 2 years ago, I did a lot of building on Windows and tried very hard to use a VM (just one layer -- a Windows 7 Virtualbox VM inside Fedora x64.) The configure times were excruciating. 6 minutes sounds about right -- for the top-level configure only. If you add in the recursive configures (js/src, libffi, I can't remember what else), it was at least 30 minutes just in configure.
>

Just for comparison, I tried this in a Windows 2003 Virtualbox VM using
2 of my AMD cores inside Fedora x64, using a magnetic disk. The
configure time for the whole of mozilla-central came in at just under 6
minutes. (I used to use Windows XP but it was about half the speed
because I could only use the IDE driver.)

--
Warning: May contain traces of nuts.

[Mike Hommey]

On Fri, Sep 20, 2013 at 02:58:26PM +0900, Mike Hommey wrote:
> When it is demonstrated to be robust, it will be made the default for
> non-releng builds (not for windows until bug 918652 is fixed somehow
> in-tree).

I just landed bug 920919 on inbound. Assuming it sticks, this means
MOZ_PSEUDO_DERECURSE=no-parallel-export is now the default for
non-pymake builds. Pymake still needs at least bug 918652 fixed. Bug
912979 would be a good thing to fix, too.

With the landing of 921070, it should be possible to make
MOZ_PSEUDO_DERECURSE=1 the default (that is, with parallel export), but
I want to have it bake for a little more before doing it. So please
continue using MOZ_PSEUDO_DERECURSE=1 if you're already volunteering for
build breakage^Wtime improvements.

> More to come in the next few days. Stay tuned.

The most notable ones are bug 905973 and bug 921003, which should be
landing hopefully soon, now.

Mike