Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-04 01:05:04

On Wednesday 03 August 2005 19:05, Craig Rodrigues wrote:
> On Fri, Jul 29, 2005 at 04:08:40PM +0400, Vladimir Prus wrote:
> > Internally, Boost.Build sorts all properties, to speed up something.
> What speeds up by sorting the properties? Is there some kind of lookup
> mechanism?

Yea. We do a lot of manipulation with property list, like "get me all
dependency properties here". If property list is just jam list, then you'd
need to iterate over all the list, call feature.attributes and this all is
very slow.

So, we have class property-set. It's always created with property-set.create
that sorts the property set and checks if property-set with the same
properties was already created. If, the previous instance is returned. Now,
most methods of property-set do caching, and do something only on first

A long time ago, when this optimization was initially implemented, we got
something like 20x speedup.

> > If you need a specific order of a specific includes pair, the current
> > syntax is
> >
> > <include>some_dir&&another_dir
> >
> > This is relatively new and untested part of the code, so feedback is very
> > welcome.
> Well, I'm not a big fan of this is non-intuitive.
> For people migrating from Makefiles, Visual Studio project files, etc.,
> it is quite surprising that the order that you specify <include>
> directories is not the order passed to the toolchain.
> For most cases, this is probably not a problem, but for huge
> oddball projects like mine, this can be a problem.

I realize, but serious performance problems we get otherwise will affect all

> Would it be possible to sort all properties, but
> maybe group <include> and <library-path> and leave them in the
> same order they were specified in a Jamfile?

I've tried to implement this idea in past, but performance has decreased 2x,
IIRC. I can test again some day, but not this week ;-)

- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at