dsimcha wrote:
== Quote from Andrei Alexandrescu ([email protected])'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
