[m-rev.] for review: version array reimplementation

[Ralph Becket]

Peter Wang, Monday, 27 July 2009:
> On 2009-07-27, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> > Peter Wang, Monday, 27 July 2009:
> > > On 2009-07-27, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> > > > 
> > > > If I recall correctly, my implementation should have ensured that the
> > > > latest version of the array was always represented as a base/1 value,
> > > > giving the O(1) properties.  Was there a bug in the code?
> > > 
> > > Oops, sorry, I misunderstood your code.  Still, something is causing it
> > > to perform a lot worse than my version.  Let me try and see why that is.
> > 
> > I think your version may be better because it doesn't penalise old
> > versions quite as much.  That said, if you are trying to make old
> > versions fast, it may pay to make old versions track usage and make
> > a new copy if the overheads become large.
> 
> Yes.  What's happening is that in mmc --make, where this is used,
> sometimes we go back to an older version of the array and continue from
> there.[1]  In your implementation as soon as you build on top of an old
> version you get the linked list behaviour.
> 
> I'm going to see if I can make ML_va_set handle this case more
> gracefully and then compare mmc --make again.

That would actually be very handy.  One of the things that has put me
off using version arrays more is the need to make copies every now and
then.  If this behaviour was automatic based on usage then that would
make them much more attractive.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------