[summerofcode] idea of speedup interpreter startup

[Brett C.]

Linan Wang wrote:
> hi, everybody,
> 
> Let's go to the topic directly :)
> I propose to use "lazy import" strategy to handle modula import. 
> The term lazy here means import the compiled function's code only
> before first using it. Sometimes we only use few functions/classes in
> a module, but it seems we import all the compiled code when we do
> importing.

Right.  Even if you do ``from module import *`` the module still ends up in
sys.modules; you just specify what ends up in your namespace.

> It's quite a waste of time and resource.

Don't know if that is fair to say.  Remember that the initial importation
executes the module.  Also remember that 'class' and 'def' are statements;
Guido has stated multiple times they should be viewed as such.  So executing
the entire module, including 'class' and 'def' is not a waste since the
semantics are straight-forward to explain.

> By introducing a function/class table at some place of compiled code,
> we can import only the definition of the module. When before firing a
> function in a module, interpreter does the real import action.
> 

So like a proxy in the module type that, if a lookup fails, goes out to the
bytecode to load the code.  A table in the bytecode could specify offsets into
the bytecode, execute the code for the module attribute, and store the result
into the proxy.

> This idea maybe considered before and abandoned because of  the cost
> of IO operation, rr, the implementation of lazy strategy for classes
> import is a quite complex.
> 
> Does this idea make sense? Any mentors want to give me some ideas?
> Thanks alot!
> 

It makes sense, but I just wonder if it is worth the added complication.  It
might be a real boon, though.  Be interesting to find out which way it goes!

-Brett