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
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
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 syntax.....it 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 ;-)
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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