Subject: Re: [Boost-build] Is there any way to prevent Boost.Build fromrecursively scanning header files for #include directives?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-04-29 11:26:19
Thorsten Ottosen wrote:
> Vladimir Prus skrev:
>> J. van der Wulp wrote:
>>> I did not have a look at any of the scanning internals. From a naive
>>> look at some level 3 debug logs I got the impression that a lot of
>>> scanning work is being done more than once.
>>> Is it possible to improve performance by caching scan results? It seems
>>> as though a lot of header files are scanned repeatedly. Or is this a
>>> consequence differences of preprocessor contexts that are taken into
>>> account by the scanner?
>>> The Big Question: do bjam/Boost Build v2 developers think that there is
>>> room for performance improvement in this regard? Does any substantial
>>> performance improvement in scanning come at the expense of correctness?
>> Most of the time taken by scanning is time inside Boost.Build code. So, caching
>> the 'raw' scanning results does not give much performance advantage. Caching
>> at a higher level is considerably harder. My current opinion is that we should
>> get Python port to a state where it can build entire Boost C++ Libraries and
>> see what performance is in that case. It might be good enough to make any
>> further tweaking not necessary.
> Why should a python port be faster than a C-based app? Just curious.
Boost.Build is not written in C. It's written in Boost.Jam's language, which is
not best performance-wize.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk