[Larceny-users] Heaps in err5rs: giant heaps, errors loading, extra slow compile with -stopcopy

[Ray Racine]

On Fri, 2008-05-16 at 17:27 -0400, Ryan Newton wrote:
> I've got a large R6RS project.  I'm having problems with compile- 
> stale and also with trying to build my libraries incrementally using  
> explicit dependencies represented in a makefile.  (I can elaborate on  
> that if anyone is curious.)

FWIW, I currently have 77 *.sls files comprising ~22500 LOC on a 64 bit
AMD, Linux Fedora

I am using -flat1 when building Larceny itself.

My current "main" program loads 86 files, 56 files in my rl3 namespace,
the rest in rnrs and err5rs.  At this moment ~5 files and < 1000 lines
of code are not pre-compiled.  All files load in err5rs mode in < 5
secs.

Adding -stopcopy appears to slow the load down slightly, maybe taking a
sec or two longer.  I haven't tried creating a heap because of extensive
FFI use in the code and I've been assuming (maybe erroneously that there
is an outstanding bug regarding heaps with FFI).

I have experienced some compile-stale-library fragility as well.  

Once I noticed compile-stale-library was compiling rnrs files in the
Larceny R6Rs library directory.  Somehow I'd touched a file in there.
After doing a larceny:compile-r6rs-runtime that issue cleared up a lot
of problems cleared up.

When necessary I do a rm $(find rl3 -name "*.slfasl") when I see
"Client was expanded against a different build of this library" and do a
fresh compile-stale-libraries which successfully completes.

This fresh compile via compile-stale-libraries takes 3 mins 15 secs on a
2 GHZ machine.

Regarding R6RS bloat.  I rigorously use (only (...) ...) on R6RS library
imports.  Don't know if this makes a difference however.

One bug/issue in compile-stale-libraries is if emacs leaves a
#myfile.sls# dropping file.  I don't recall exactly the error but the
stale library compile blows up if one of those files exists.