Array append performance

dsimcha dsimcha at yahoo.com
Sat Aug 23 10:50:08 PDT 2008


== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> I see nothing wrong with having a library solution to this.  D and
> especially D2 is to the point where syntax of custom structs is really easy
> to use.
> The problem is that many times I don't append to an array or slice, why
> should I have to accept the cost of an extra 4-8 byte field for every slice
> and array that isn't going to change size (which I would argue is used more
> often)?
> The only thing missing right now is opImplicitCast (to go back and forth
> from a normal array).
> -Steve

You do have a point there.  Builtin arrays work well for the typical cases, but no
one array type could work well for every conceivable specialized case, especially
if you count the case of needing minimal overhead as one possible specialized case.

I've wanted to write my own specialized array classes to deal with these unusual
cases for a while, but the lack of opImplicitCast is the only thing that prevents
me from doing so, since I would want them to be able to play nice with builtin arrays.

A little off topic, but somewhat relevant:  I wrote a scope array class for when
you need a to allocate large temporary array for something like a mathematical
computation or a merge sort, without constantly triggering GC or running into
false pointer issues.  It bypasses the GC, calls C's malloc, realloc and free,
and, since it's a scope class, the memory is freed by the dtor.  Does anyone know
if DMD's std.c.stdlib.malloc/free/realloc are threadsafe?



More information about the Digitalmars-d mailing list