On Fri, 14 Mar 2014 06:06:41 -0400, Don <x...@nospam.com> wrote:
On Thursday, 13 March 2014 at 19:28:59 UTC, Walter Bright wrote:
On 3/13/2014 1:43 AM, Don wrote:
The worst breaking change in D2, by far, is the prevention of array
stomping.
After that change, our code still runs, and produces exactly the same
results,
but it is so slow that it's completely unusable. This one of the main
reasons
we're still using D1.
I didn't know this. I'd like more details - perhaps I can help with how
to deal with it.
Our entire codebase assumes that stomping will happen. Simplest example:
T[] dupArray(T)(ref T[] dest, T[] src)
{
dest.length = src.length;
if (src.length) {
dest[] = src[];
}
return dest;
}
OK, thanks. This is not the same as setting length to 0. You would have to
re-introduce stomping completely to fix this without modification, and
that will break too much library code. My proposed idea is not going to
help here.
Fixing this function involves adding assumeSafeAppend:
T[] dupArray(T)(ref T[] dest, T[] src)
{
dest.length = src.length;
dest.assumeSafeAppend();
... // the rest is the same.
}
This is equivalent to dest = src.dup, but if dest was already long
enough to contain src, no allocation occurs.
Sure, we can add a call to "assumeSafeAppend()" everywhere. And I mean
*everywhere*. Every single instance of array creation or concatentation,
without exception. Almost every array in our codebase is affected by
this.
Only array shrinking. Concatenation always allocates. Doing it after
append is redundant. Doing it after creation is redundant.
Doing it *before* appending is possibly proactive, but I think just doing
it whenever the length might shrink is good enough.
I think it may be best to introduce a new array property:
dest.slength = src.length; // same as dest.length = src.length, but
follows D1 rules (slength = stomp length)
If you use slicing (I'm assuming you do), then appending would have to
become a function/member instead of ~=.
I can help write those if you want.
-Steve
