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

Peter Wang novalazy at gmail.com
Mon Jul 27 15:04:48 AEST 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.

Peter

[1] If I find where it happens I'll try unsafe_rewind.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the reviews mailing list