[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