Boost logo

Boost-Build :

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-05 08:53:12


Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>> > The 'modules.mormalize-raw-paths' takes more time than actually building
>> > targets! I think that now that "import" is required in every class, and
>> > is called during construction of all instances, we *really* need to
>> > optimize it -- and in particular, it should not call
>> > 'normalize-raw-paths' in such a way. Thoughs?
>>
>> I think we should optimize normalize-raw-paths; it would be easy to
>> make a cache of results or to stop work on a path when all of its '.'
>> characters have been processed. I think the cache is probably the
>> way to go, though.
>
> First off, I think there's no point to normalize all those paths, unless
> you're really going to load the module.

The point of normalizing the path is that we don't want to change the
load priority order for directories which are already in
BOOST_BUILD_PATH, because it would result in highly unpredictable
behavior if a different module could be loaded based on the directory
of the module doing the loading. You can only detect that if you can
compare the paths effectively.

> The attached patch reduces the number of 'normalize-raw-paths'
> invocations from 1544 to 76, which translates into considerable
> run-time reduction.

Great!

> After than, caching can help, but:
> 1. I don't really understand why we need to use 'normalize-raw-paths'. When I
> change it to return its argument, all tests pass for me on Linux.

Explained above.

> 2. It's not that good idea to duplicate functionality already in path.jam.

The implementation of path.join (which is close to what that rule
does) is so complicated that I had no confidence that it was doing
what I wanted, plus it would have drawn path.jam into the kernel, plus
I didn't want to translate the path to the internal path format and
back to native just to get this job done. Feel free to find a better
solution.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
 

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