bjam performance [was: how to skip regenerating the dependency tree]

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2004-05-05 05:39:20

David Abrahams wrote:

> And, as Rene explained, nothing you can
> do with the .jamdeps file is going to improve matters much because
> dependency scanning is not where most of the time goes.

So I was interested in this info and tried to get a profile of a typical 
bjam run. So I ran 'bjam lib' on my project with all targets up to date 
to avoid influencing the timing with calls to the compiler or linker.

First conclusions :
25% of time is spend in hashitem, 19% in string_append and 15% in 
var_expand (the total run took 264 seconds) (profile in attach)

The 'string_append' surprises me though and I wonder also if the code 
could benefit from a using a memory pool. As far as the hashitem is 
concerned, I have no clear visibility on what it's doing.

I'm going to look into this a bit more in the future (actually I've put 
it in my planning) and hope to be able to have some time in a month or so.

toon

 --------------060306000808080100050406 Content-Type: application/x-zip-compressed;
name="gprof.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="gprof.zip"

[Attachment content not displayed.] --------------060306000808080100050406--