Re: IMPORT_MODULE proposal

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?

Only:

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
www.boost-consulting.com