Short list with things to finish for D2

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> Yes, it will be because the book has a few failing unittests. In fact, I
>> was hoping I could talk you or David into doing it :o).
>> Andrei
> 
> Unfortunately, I've come to hate the MRU idea because it would fail miserably for
> large arrays.  I've explained this before, but not particularly thoroughly, so
> I'll try to explain it more thoroughly here.  Let's say you have an array that
> takes up more than half of the total memory you are using.  You try to append to
> it and:
> 
> 1.  The GC runs.  The MRU cache is therefore cleared.
> 
> 2.  Your append succeeds, but the array is reallocated.
> 
> 3.  You try to append again.  Now, because you have a huge piece of garbage that
> you just created by reallocating on the last append, the GC needs to run again.
> The MRU cache is cleared again.
> 
> 4.  Goto 2.

This is not a matter of principles, but one of implementation. When you 
GC, you can adjust the cache instead of clearing it.

> Basically, for really huge arrays, we will have the nasty surprise that arrays are
> reallocated almost every time.  Unless something can be done about this, my vote
> is as follows:
> 
> 1.  a ~= b -> syntactic sugar for a = a ~ b.  It's inefficient, but at least it's
> predictably inefficient and people won't use it if they care at all about performance.
> 
> 2.  .length always reallocates when increasing the length of the array.
> 
> 3.  Get a library type with identical syntax to slices that truly owns its
> contents and supports efficient appending, resizing, etc.  I'd be willing to write
> this (and even write it soon) if noone else wants to, especially since I think we
> might be able to use it to define unique ownership for arrays to allow essentially
> a safe assumeUnique for arrays and kill two birds w/ one stone.

UniqueArray is something we need regardless - for message passing.


Andrei