Well, feel free to submit a patch. I'm just telling you that I don't believe making it more parallel will make anything faster, except maybe in some very contrieved example cases. But again, feel free to experiment. If you really manage to make my builds faster, I will not complain.
Visual Studio compiles a lot faster because MSVC is a much faster (and lower quality) compiler than gcc. This is more true under Windows than under Linux too, because the GNU-style absurd number of process creations is not very efficient. It is not uncommon that for compiling a single source, a chain of 5 or 6 executables is launched. This somewhat less of a problem under Linux, since it is not
that painfully devastative, but it is much more disturbing under Windows. Visual Studio only ever loads the compiler
once, for the entire workspace.
Also, in particular GNU
ld is the most terrible thing on earth, which is why link times often dominate the build process by far.
Though you can use an alternative linker, which is even officially supported via plugins in the mean time, if that is a problem. There exist some which are an order of magnitude faster, too.
On my development systems, compile times under Windows are bound by both process creation
and IO. Under Linux, they are bound by IO alone. No matter how many parallel builds I start (the sweet spot is 5 for me), CPU usage never comes even close to 100%.
Linking using
ld literally causes millions of seeks on moderately large projects. Solid state and ram drives help, but do not make the problem go away. As such, IO
is a dominating factor, and my guess is that adding
more seeks does not improve the situation.