|
Boost : |
Subject: Re: [boost] [PREDEF] Review for the Boost.Predef library by Rene Riviera
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-02-22 03:28:26
On 02/21/2012 11:09 AM, Artyom Beilis wrote:
>>> When you include a header like<boost/predef.h>
>
>>> you get 103 files included... 103 stats, fopen, fclose,
>>> read parse and so on.
>>>
>>> More then that, consider build systems that should stat 103 files
>>> for each cpp file compiled.
>>
>> One option I can think of is to provide a single
>> concatenated header that is generated from the current modular headers. This, of
>> course is a bit more work on the library side, and is considerably harder for
>> users to humanly understand one big concatenated header file.
>
> But easier to compiler... :-)
I am strongly opposed to this! First of all, it is the job of the
compiler to compile. In theory, it doesn't matter how many files he
needs to open to get the job done. However, it matters for us humans.
Is this just over pessimistic, premature optimization?
>> Hence this is
>> something that I would seriously consider adjusting if the number of headers
>> becomes a real measurable problem. Which also suggests that I should add some
>> header parsing performance tests.
>
> The problem is not header parsing performance only. Every build
> system checks dependencies, that means it stats() all the files
> it makes the process slower.
>
> So even if the process of parsing and stating takes only 0.1s it becomes critical
> for many files.
What you are suggesting effectively sounds like throwing all kinds of
structure and file organization away that makes sense for us mere humans
just to compile a little faster. Please, back it up with some proof.
Additionally, i would like to add that a fine grained header file
organization also leads to less includes. One might always need
everything defined in the library in one TU. I claim that having those
big headers is slowing the process down.
So, how big is the impact? Did you do some real measurements?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk