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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk