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