[gambit-list] Gambit's Linking Model

Marc Feeley feeley at iro.umontreal.ca
Wed Jun 13 21:13:30 EDT 2007

Hash: SHA1

On 13-Jun-07, at 5:36 PM, Guillaume Cartier wrote:

> Hi everyone,
> Unfortunately, I think I have stumbled upon a major problem for my
> project with the linking model of Gambit / Scheme's lack of
> specification for linking code.
> For my applications I absolutly need the ability to be able to load  
> code
> selectively. If I understand correctly, the Gambit linking model is  
> that
> all classes compiled into a .exe are loaded upon launching the .exe so
> that cannot do for me.
> The only alternative I see is the use of .o1 loadable code but is it
> reasonable to dynamically load like 1000+ .o1 files?

To evaluate how "reasonable" this is I wrote a script to generate  
1000 .scm files.  Each contains a dozen Scheme functions which  
compile down to a 54 KB dynamic library (.o1 file).  According to  
"nm" each file contains about 36 KB of executable code, so that's a  
total of 36 MB of code (which is probably an order of magnitude  
larger than a big application).

I then wrote the following file (go.scm):

(load "mod-000000.o1")
(load "mod-000001.o1")
(load "mod-0000999.o1")
(pp (fn-000047 0))

And loaded it into the Gambit interpreter running on a MacBook Pro.   
Here's the timing of a few runs:

% time gsi go.scm

real	0m1.868s
user	0m0.353s
sys	0m0.450s
% time gsi go.scm

real	0m0.895s
user	0m0.328s
sys	0m0.394s
% time gsi go.scm

real	0m0.899s
user	0m0.326s
sys	0m0.387s

You can see that the second and third runs are faster than the first  
one, because the files have been loaded into the disk cache.  When  
the number of .o1 files is lowered to 100 files the timing is:

% time gsi go.scm

real	0m0.229s
user	0m0.192s
sys	0m0.034s

So it takes about one second of real time to load 36 MB of executable  
code distributed in 1000 .o1 files and about a quarter of a second of  
real time to load 3.6 MB of executable code distributed in 100 .o1  

I think that is reasonable.

> Wouldn't launching
> incur a huge penalty in speed / space vs a selfcontained .exe as every
> .o1 is a full fleged dynamic library? Also, with this approach,
> distributing to my clients a folder containing 1000 .o1 files is
> everything but nice.

Why is that a problem?  You just need to package your .o1 files in  
a .tar.gz and have a package installer that unpacks the archive at  
the appropriate place.  In fact that's essentially how the Snow  
framework operates.

> I could zip them together a bit like interpreted
> languages like Python do but then I don't think Windows or Gambit  
> or ...
> can load .o1 files from a zip directly so I'd have to unzip them to a
> temp folder which is again not very tempting.
> Any help / thoughts really appreciated. This is criticaly for my using
> Gambit for my project.

I don't really see a problem with this (either performance or  


Version: GnuPG v1.4.3 (Darwin)


More information about the Gambit-list mailing list