Guile (Guile Startup Time Reduction)

Project GNU's extension language


What is Guile?

Recent news

Getting Guile

Helping out

Mailing lists

Documentation

FAQ's

Guile Projects.

Cool ideas

Other Resources

Home

Starting Faster

Reducing the startup time of Guile

The first thing you will notice when you fire up Guile is that it takes quite some time before the prompt appears. The starting point for the current Guile implementation, the Scheme system SCM, is very fast. Guile has lost some of this speed as it acquired new features. In the following I'll point out some of these things and what you can do about them.

One reason is that Guile loads a fairly large file of Scheme code to initialize itself. This file is much larger than it needs to be and one can prune it to only include what's really needed. Now that might be an easy solution and in fact, the boot code will sometime be split into modules that are loaded on demand. But sooner or later the amount of Scheme code that has to be loaded for your typical Guile application will become a problem again. So we still need a way to speed up loading of Scheme code in general.

The second reason for a slow startup time might be the debugger. Guile actually sports two interpreters: one for normal code evaluation that has been seriously tuned for performance (the original one from SCM) and one that collects some information during evaluation to support several debugging features. Naturally, the debugging evaluator is slower (but not much) than the normal one. You can control which evaluator is used with

(debug-enable 'debug) ; to enable the debugging version

and

(debug-disable 'debug) ; to enable the normal one

But during boot up the debugger is disabled anyway.

The module system of Guile is currently implemented in Scheme and this is said to alone double the start time. When more of it is rewritten in C, we are likely to see an improvement.

Then there is the `freezer'. It can take a file of Scheme source code and convert it into a static C array that contains the runtime representation of the code. The C code can then be compiled and linked into your application. At startup the Scheme code doesn't have to be read because it's already there. The freezer is only an experiment and has been neglected for some time now.


freezer.tar.gz is still available.

The most promising route seems to be `unexec' (at least to me). That is, as long as you can get it to work at all. `Unexec' or dumping is the mechanism used by Emacs to preload much of its Lisp code. It is highly system dependent and not even guaranteed to work. Each part of your program has to be checked if it works with unexec. Libguile itself should be safe as is most of the C library.


guile-unexec is also available.

The best longterm solution is probably a real Scheme to C compiler. There already is Hobbit for SCM and it can be made to work with Guile. Please see Bernard URBANS post to comp.lang.scheme for more information.


2 Aug 2000 spacey


Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

Please send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.

Copyright (C) 2000 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA

Verbatim copying and distribution of this entire web page is permitted in any medium, provided this notice is preserved.

Updated: 2 Aug 2000 spacey