[MLton-devel] upcoming public release
Stephen Weeks
MLton@mlton.org
Thu, 30 Jan 2003 23:11:04 -0800
> My impression is that the current GC takes everything alive in the nursery
> when the nursery fills up, and copies it to what is essentially the next older
> generation than the nuersery.
Right. We have only two generations.
> I guess that that should make the ephemeral stuff pretty cheap since
> it probably won't be alive then.
Yes. But the relevant point is not comparing ephemeral allocation to
long-lived allocation. The relevant point is comparing lots of
ephemeral allocation to less ephemeral allocation.
> If so then the saving of avoiding the reversal should be pretty
> minimal, shouldn't it? I.e., it is never GC'd, so it is only the
> actual reversint time.
Yes, it is only the actual reverse time. But I claim that's a lot,
and a significant fraction of what's going on in the code. Think of
it another way: if you have code that reverses a list 2,000,000 times
and convert it to a piece of code that reverses a list 1,000,000
times, you're gonna cut allocation and time in half. In looking at
the code, I saw a lot of list allocations followed by reversals,
without much else in some places, and in particular in some hot
spots. So, I figure we can get almost the factor of 1/2 in some
places. The kind of GC is completely irrelevant.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel