Boost logo

Boost-Build :

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-07-28 09:08:31

Vladimir Prus <ghost_at_[hidden]> writes:

> I'm currently considering some optimization, and posting my ideas to the list
> to benefit from peer review.
> Looking at the bjam profile on my project, I see that IMPORT and RULENAMES
> builtins take a lot of time. The possible reason is this: each class instance
> is actually a module. So, "import" statements inside classes are executed
> once for each instance. And wholesale imports like
> import target ;
> cause V2 to
> 1. finding all rules in "targets" via RULENAMES
> 2. importing them all via "IMPORT"
> which is probably the cause. My guess is backed up by the fact that there are
> only 7000 instances created, while RULENAMES is called 36000 times. It can't
> be due to loading of ordinary modules.
> I propose to introduce new builtin IMPORT_MODULE. After "IMPORT_MODULE b " is
> called in module a, "b" will be added to the list of imported modules. Name
> lookup for rule will work like this:
> - lookup the rule in this module
> - if not found, and name is in the form something1.something2 and "something1"
> is in the list of imported modules, look for "something2" in module
> "something1".
> I think this should reduce memory usage and time needed for RULENAMES/IMPORT.
> Are there any pitfalls I've missed?


1. It's a bit of a hack (not that that has ever stopped us in
the past, when it comes to the Jam core ;->)

2. it might slow down actual rule lookups.

3. I don't think it will help in many cases. For example, I
think when we do inheritance it imports the rules as
non-dotted names.

Maybe it would be better to:

A. refactor modules.import so that it calls a different rule for
"wholesale imports", then profile again

B. sink the entire code for the offending import functionality
into 'C'

Dave Abrahams
Boost Consulting

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