Re: Evolution & optimization of the module system

[Ludovic Courtès]

Hi,

Kevin Ryde <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:
>>
>> The measurements in the `module-duplicates.scm' file I posted choose
>> USES = 10000 by default, which is arguably unrealistic.
>
> Was that 10000 imported modules?  That's well outside the realm of
> reason! :)

Right.  :-)

> Normally there'll be perhaps up to 20 imports, so there
> should be no call to change unless that sort of quantity is hurting
> badly (which I would say I've never noticed it doing).

Well it _does_ hurt, even with real-life numbers of imports, as the
experiments I made tend to show (I'm talking about the measurements made
on real applications, not the synthetic evaluation in
`module-duplicates.scm').  I really encourage everyone to apply the
patch and make timing measurements on their own applications, so that we
get better insight about the benefits of the changes.

Alternatively, we could start thinking about the module system "from
scratch".  From a performance viewpoint, the question is: how can we
provide the fastest variable lookup and duplicate binding detection,
i.e., using what data structures and algorithms?

Hopefully it is now clear that improvements can be made over the current
implementation in these respects.  Then, how?


I'm not sure other interpreters provide such sophisticated module
systems.  SLIB's `require' is much simpler for instance, and SCSH (or is
it Scheme48?) doesn't seem to address duplicate binding detection
according to the "Module Warning" note in Section 11.1.3 of the manual
for version 0.6.7.

Thanks,
Ludovic.