Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-09-14 08:23:36

At 11:42 AM 9/9/2003, Dan Muller wrote:
>One of our developers tried gathering all of the boost includes from the
>database layer into one header file, to which he also added a "pragma
>once". He replaced all boost-related includes with a reference to this
>file. Finally, he included this file in the UI-level project's
>precompiled headers. Build time was reduced by half. Similar reductions
>(one-third to one-half) have been noted in other projects affected by
>this. I'm not particularly happy with this solution from a maintenance
>perspective, though.
>It would be really helpful to those of us working with VC if boost
>developers were encouraged to use #pragma once, suitably guarded. I
>would think that a global boost configuration setting, defaulted
>appropriately per compiler, could be used to guard it.

I'm not necessarily adverse to encouraging use of a Boost macro wrapping
#pragma once, but would like to better understand the problem first. I'm
wondering if this is a general problem, or the slowdown you see is specific
to your use patterns or compiling environment.

I tried so tests here, on a 1.8 GHz notebook machine with a half a gig of
main memory, running Win XP. I used the VC++ 7.1 timed build feature to
measure time.

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:

    -- Running on a machine with very limited memory.
    -- Running on a machine heavily loaded with other processes.
    -- Files located across a network such that caching is defeated.
    -- O/S configured to defeat caching.

If what is slowing your builds is something very specific to your
environment then the motivation for a BOOST_ONCE macro is much less than if
the problem is caused by some factor likely to affect many users.

A completely different line of thought: Presumably all Boost headers are
not used by your programs in the same relative proportions. Is there a
relatively small list of headers which cause the bulk of the slowdown?


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