Re: [boost] Re: #pragma once again

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) 
took
 >> 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 
reflect
 >> XP's caching of config.hpp and its dependencies.
 >>
 >> If I understand your experience, adding 100 includes of config.hpp to 
one
 >> of your programs would serious slow the build time by some amount of 
time
 >> that is significant - several seconds if not a lot more - and scales up 

 >as
 >> 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 
working
 >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 
boost/config.hpp.

 >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
 >misses.

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?

--Beman