Mark Roulo (nothanks@xxx.com) on 6/29/10 wrote:
---------------------------
>Richard Cownie (tich@pobox.com) on 6/28/10 wrote:
>---------------------------
>>Second, there's a trade-off to be made between the effort
>>put into making builds go fast, and the total time spent
>>by all developers waiting for slow builds. If you're
>>planning to have hundreds or even thousands of developers,
>>as for the Linux kernel, then it's good to spend a lot of
>>effort making builds go fast (and use compute resources
>>efficiently); if you have 20-50 developers, then it may
>>make more sense to spend $20K on a compile farm rather
>>than say 2 man-years on making single-machine builds go
>>fast. Horses for courses.
>>
>
>Yes.
>
>Another way to look at this, though, is that the compiler developers (ICC, GCC,
>MSVC++) should be willing to spend *their* developer resources ensuring that their
>tools run quickly. After all, their user base is 10s of thousands, if not 100s of thousands.
>
>Kinda the same logic by which we expect/hope that the OS kernel is very parsimonious with RAM and clock cycles.


Actually I want the tool chain developers spending their time making *me* more productive. They need to focus on compiler performance to the extent that faster compiles help my productivity.

FWIW, the thing that's generated the biggest increase in build time for me in the last few years is link time code generation. It not only reduces the incremental nature of most builds (the compiler ends up doing most of the hard work when building the executable, and then having to do *all* of that work each time anything in the executable is touched), it also reduces the scope for parallelism in the build process.