Re: [Boost-build] Is there any way to prevent Boost.Build fromrecursively scanning header files for #include directives?

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.

- Volodya