Re: srfi-18 and the vm

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> Hello,
>
> Andy Wingo <address@hidden> writes:
>
>> For loading uncompiled scripts, things will be slower, unless your
>> modules #:use-syntax some other transformer. I don't know where the
>> tradeoff is between the increased expansion speed due to compilation and
>> slowdown due to a complete codewalk, but it's certainly there.
>
> Yes.  Likewise, it may be reasonable to assume from now on that most of
> the code will be compiled.  For instance, an uncompiled script may just
> be a small code snipped that uses mostly compiled code.

It seems to me that once we have a completely working compiler, we
need to ask if there are any circumstances left where it is better to
use the current interpreter instead.

If the answer to that is yes, the details of those remaining
circumstances will (probably) make it obvious whether the
pre-memoization idea is worthwhile.

Do we already have performance measurements, and are those recorded /
summarized somewhere?

>> OTOH I would suspect that we can implement some kind of just-in-time
>> compilation -- essentially for each use-modules we can check to see if
>> the module is compiled, and if not just compile it then and there. It
>> would be a little slow the first time, but after that it would load much
>> faster, even faster than before. Python does this. We could add a guile
>> --no-comp option to disable it.
>
> I don't like this idea because it implies implicitly letting Guile
> fiddle with the user's file system.

I don't see why that should be.  Isn't it possible to read a .scm
file, compile its contents, and hold the compiled programs in memory?

Regards,
        Neil