[MLton-devel] upcoming public release

[Stephen Weeks]

> 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