Re: [jamboost] Boost.Build stress test

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-19 08:02:06

David Abrahams wrote:

> > This means that performance optimization is yet to be done, and as we
> > discover performance problems (with the help of big projects like yours),
> > we'll fix them. Attempting to predict how much performance we'll get is
> > impossible. But I think considerable improvement is possible. After all,
> > we can add as many Jam builins as we'd need, and C is fast.
>
> Are we sure this one wasn't due to header scanning? AFAIK we haven't
> turned on the header dependency cache yet. That's so trivial to do
> that it seems like low-hanging fruit.

I think I've done some experiments, and they wasn't very successfull. The 
problem is that Jam code for handling includes is slow, and it's called quite 
a big number of times -- because build dir of current project is added to 
includes, and many headers are scanned several times with different 
<includes>.

BTW, note a problem with "" includes. There's no reason that 

#include "boost/a.hpp" 

means the same in

boost/graph/header1.hpp

and in

boost/python/header2.hpp

so it can cause increase in the number of targets to process. I think this
affect V1 as well, though.

- Volodya