Change representation of dynamic arrays?

[Daniel Keep]

0ffh wrote:
> Daniel Keep wrote:
>> You say you've measured the performance of loops using this, but what
>> about slicing code?  I know that I use a lot of [lower..$-something]
>> style code; how much slower does this become?  Once I'm not so busy, I
>> might try to work out the proportion of foreach to $ slicing in my
>> code. :P
> 
> I guess we go from changing one pointer and a size_t to changing two
> pointers, I can't see a lot of space for that being slower than now.
> 
> Consider:
>   wchar[] str="this is a test";
>   int s=10; // slice start
>   int e=14; // slice end
>   tst=s[s..e];
> Old array:
>   tst.ptr=str.ptr+s*wchar.sizeof;
>   tst.len=e-s;
> New array:
>   tst.start=str.start+s*wchar.sizeof;
>   tst.end=str.start+e*wchar.sizeof;
> 
> Regards, Frank

Well, that's definitely more work to compute end, although in most
cases, the multiply could be reduced to a bit shift.  I was talking
about cases where we slice using the length of the array, since now we
have to actually go and compute the length instead of simply looking it up.

e = 2;
tst = str[s .. $-e];

Old array:

tst.ptr = str.ptr + s*wchar.sizeof;
tst.len = (str.length-e) - s;

New array:

tst.start = str.start + s*wchar.sizeof;
//tst.end = str.start + (str.length-e)*wchar.sizeof;
tst.end   = str.start + ((str.end-str.start)-e)*wchar.sizeof;

So we've gone from two subtractions to an addition, two subtractions and
a multiply; that's double the number of operations, one of which is an
expensive multiply.  If the primary justification for this change is
eliminating a decrement operation for iteration, I think it's very
relevant to look at how it's going to affect other code!

	-- Daniel