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
> 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
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
-- 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