On 03/22/2010 10:38 AM, Steve Schveighoffer wrote:
----- Original Message ----
From: Andrei Alexandrescu<[email protected]> Yes, but at the end of
the day, you do have a primitive that tells you whether a given
array extends to the end of a given block and consequently is ok to
append to in-place. Correct?
The cache is not that. That primitive is determined by the GC block
info. Essentially, with the blockinfo, I can tell where an array
ends, and therefore know whether it can be appended in place. This
is true regardless of whether the blockinfo is in the cache or not.
The cache simply allows me to skip the expensive blockinfo lookup.
Essentially, by removing a blockinfo from the cache, it doesn't
prevent any behavior, it just makes it slower.
OK.
You told me that for best results I need to do:
arr.length = 0; arr.assumeSafeAppend();
The last call makes the system assume that I saved no subarray of
arr that I'm interested in keeping. No?
Yes. I think I see where you were going with the request. You want
to remove that second line? It simply does not work, because an
array isn't marked differently because it was sliced, and the runtime
cannot tell.
What about code like this:
auto arr2 = arr; arr2.length = 0;
Yeah, it looks like array assignment also needs to be hooked.
Now, if you assume because the user used length instead of slicing,
it's ok to append, what happens to arr? That is why we need the
assume call. To get what you want, any time an array is copied, even
via function calls, you'd have to kill appending to it. I don't
think that it's worth the performance loss on the common operations
in order to save a line of code in an uncommon situation.
I agree.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
