Re: Guile Startup Time Suggestion

["Wade Humeniuk" <humeniuw@cadvision.com>]

> Perry Metzger Writes:
>
>That's totally incorrect -- it isn't even remotely accurate. Other
>interpreted languages like Perl start up nice and quick, so it is
>obviously not a system problem -- it is a problem with Guile. We can
>make Guile work as well as Perl if we want, and without kludges.
>

I agree that it would be an optimal solution to change Guile
(fix is the wrong word).  But there are some assumptions that
I am making.  The first is that the Guile code is based on other
implementations of Lisp where those developers worked
on the same problems and agonized over the tradeoffs.
So the Guile code is, as good as it gets, and I would not like
to second guess the implementors.  However I am
undaunted and am willing to look for ways to change
Guile fundamentally.  Looking at the code and previous posts
I have come up some questions and insights and propose
a coding solution.

The first question I have to ask is there a Lisp which starts quickly?
If there is, how does it do it?  And do the Guile implementors want
to do the same thing?  When I say quicky enough I asssume as quickly as
Perl.

Jim Blandy stated in previous posts that:

1) Guile's startup time has to do with loading the initialization files. Why
is it
necessary to load these files?  Can this be avoided?  Jim also
said that this would not fix the problem as the initilization would
become larger as time went along.

2) Doing an unexec on the Guile image could work but they did
not want to do that.  He said something about it being dangerous.

I think one of the goals for the Guile implementation is to
be portable, meaning non Unix-like systems.

A possible coding solution:

With the above issues I have looked at the code and observed that
the dynamic initialization of the symbol table for core functions, such
as strings, chars, etc.,etc. (See function scm_boot_guile_1 in init.c) looks
takes up a great deal of the startup time.
My basic idea is to hard code this initialization,
so that static C byte array could contain the initial symbol table.
This is a very difficult coding problem and strongly couples modules
making for maintenence problems.  Perhaps a tool could be built or some
super-duper C macro.  If this change could be made it could
be extended for any compiled library.  Any comments anyone?
When I get back from my vacation I will give it a shot.

I do not know Perl, but I would suggest that it does not do any
dynamic initialization of core functionality and is able to
begin script processing almost immediately after the system calls
main().  To get Guile to run faster we have to do the same thing.

Wade