On 08/03/2016 09:33 PM, Mark J Twain wrote:
The built in array is mutable and exposes the same interface for the
immutable copy. The only difference is that the immutable copy is marked
immutable.
I don't understand. An immutable array does not let you overwrite
elements. A mutable array does. So they have different interfaces, don't
they?
My method changes the interface. An "immutable" type has an immutable
interface while a mutable type has a mutable interface.
For simple types, and value types, there is obviously no advantage...
their interfaces are essentially empty/DNE.
Can you show some example code where there is an advantage over built-in
arrays?
[...]
As far as I see, "marking for reuse" is practically the same as
freeing here. If Data were static, there could be a difference.
For built-in arrays, you can mark an array for reuse by setting the
length to 0 and calling assumeSafeAppend, like so:
No again. Data in the example above is a local variable that allocates
memory that would generally be free'ed at the end of the function call.
Hence every call to foo results in a malloc/free pair for Data. By
reusing the memory, if possible, one can potentially skip the
malloc/free. Therefore instead of potentially thrashing the memory
pool, after a few runs of foo, Data would generally not allocate.
[...]
Your assumeSafeAppend works while the object is in existence. This thing
works between the existence of the object.
The allocator (e.g. the GC) is free to reuse memory it obtained from the
operating system. So repeatedly allocating and freeing the same amount
of memory can already be faster than one might think.
Of course, the compiler is also free to reuse stuff, if it's guaranteed
that no reference escapes the function. I don't expect dmd to do stuff
like this. ldc or gdc might.
What do Mutable/ImmutableArray enable beyond this? What do they do that
built-in arrays don't? Again, example code would help doofuses like me
make sense of this.
