Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-09-14 14:53:43

At 01:44 PM 9/14/2003, Pavel Vozenilek wrote:
>"Beman Dawes" <bdawes_at_[hidden]> wrote
>> A "hello iostream world" program rebuild (which does a clean first)
>> less than one second. Adding #include <boost/config.hpp> still produced
>> rebuild times less than a second. Even with 100 config.hpp includes,
>> rebuild time was still less than a second. I assume these results
>> XP's caching of config.hpp and its dependencies.
>> If I understand your experience, adding 100 includes of config.hpp to
>> of your programs would serious slow the build time by some amount of
>> that is significant - several seconds if not a lot more - and scales up

>> the number of includes are increased.
>> My guess is that for your builds something is defeating the operating
>> system's file caching. Perhaps:
>"Hello World" is not representative. Everything stays in cache and
>set is small.

Yes, of course. That's the point. "Hello World" is representative of a
program where all the files stay in the cache. So we know from it that
caching is effective, and thus the problem isn't an inherent aspect of

>Compiling large translation unit may eat hundreths MB of RAM and
><config.hpp> woudn't be kept in system cache. Reloading it and its
>dependencies is what slows compilation down, together witch CPU cache

If a program only uses hundreds of megabytes, caching should still be
effective. Presumably a machine used for larger builds has enough memory to
cache that much effectively, unless there is some other factor. Thus my
question about possible factors which might defeat caching.

>Intel C++, in release mode, is example of such hungry compiler.

Wasn't the issue with the Microsoft compiler?


Boost list run by bdawes at, gregod at, cpdaniel at, john at