Array append performance

Sean Kelly sean at invisibleduck.org
Fri Aug 22 17:42:46 PDT 2008


bearophile wrote:
> I have performed another small benchmark of the dynamic array append, similar to one I have performed in the past, a comparison between the C++ push_back of C++ and the ~= of D, both performed after a "reserve".
> 
> To perform the "reserve" in D I have used std.gc.malloc instead of the simpler:
> auto a = new int[n];
> a.length = 0;
> to actually speed up the D code a little, avoiding a (fast but useless) memory cleaning.
> 
> I have used MinGW 4.2.1 and DMD v.1.034.
> 
> Compiling the C++ with:
> -O3 -s
> and the D with:
> -O -release -inline
> 
> The following results are with n = 100_000_000 (about 400 MB RAM used):
>   D:   7.94 s
>   C++: 0.60 s  (13.2X)
> 
> Note that if n is 10 or even 100 times smaller the situation doesn't change much:
> n = 10_000_000:
>   D:   0.83 s
>   C++: 0.09 s

Unfortunately, this is expected.  On every append the runtime checks to 
see if there is enough room in the buffer for the new data, which 
requires a call to gc.capacity().  So best case you're paying for a 
bunch of math and worst case you have to acquire the GC mutex as well.

That said, this isn't really an entirely fair comparison, since you're 
comparing the performance of a structured, local user-level object vs. a 
minimal, language-level feature.  I know that D arrays are supposed to 
be roughly comparable to std::vector or std::string, and they are from a 
semantics perspective, but when the only local data they contain is a 
pointer and a length there's little that can be done to optimize certain 
behavior.  And you've just happened to pinpoint the greatest performance 
problem with D arrays :-)


Sean



More information about the Digitalmars-d mailing list