[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MzScheme for Embedding
Well, I was thinking of long-running Scheme programs, e.g., DrScheme on my
workstations, where I tend to keep it up forever, just opening new buffers
and old files. It grows and grows and grows. It is my impression, that
Hans's non-cooperative collector can hang on to a page just because there
is some apparently reachable pointer into it. This is impossible with a
generational copy collector. It would compress the heap.
I didn't think of the start-up footprint, which is large. Correct. Period.
-- Matthias
From: Matthew Flatt <mflatt@cs.utah.edu>
CC: matthias@rice.edu, plt-scheme@fast.cs.utah.edu
Date: Fri, 5 May 2000 20:14:30 -0700
Quoting Brent Fulgham:
> > (B) MzScheme seems like it has a fairly large memory footprint.
> >
> > Yes, it does. Matthew is working on a version that will use
> > generational copy collection in addition to Hans's "non-cooperative"
> > collector. We're testing it now.
> >
> Fantastic. Any ideas on what kind of improvement this might yield?
In this case, Matthias blames conservative ("non-cooperative") GC a bit
too much. Precise GC might make MzScheme's initial footprint 10%
smaller, or it might be 10% bigger; it mostly depends on how the
collector is tuned.
The reason I'm working on precise GC is long-term performance and
predictability, rather than short-term effects. Actually, my experience
with precise GC so far confirms that conservative GC works remarkably
well in the short term. Of course, the longer a program runs,
conservative GC's little approximations take their toll, magnified by
an inability to compact the heap.
----------------------------------------
To go back to the original question: I've never been comfortable with
the size of MzScheme's initial footprint. Despite occasional attempts,
I haven't been able to shrink it significantly. But the footprint
hasn't grown significantly, either, at least in the last two years.
Matthew