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
BTW, note a problem with "" includes. There's no reason that
means the same in
so it can cause increase in the number of targets to process. I think this
affect V1 as well, though.
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