More embarrassing microbenchmars for D's GC.

[Michael Neumann]

Leandro Lucarella wrote:
> I've done a very simple microbenchmark testing a single linked list.
> 
> What the test does is fill the list with long elements, and then iterate
> the list and increment the associated value. This test mostly test the
> allocation speed.
> 
> I've done plain a C version, a C++ version (using STL double-linked list,
> so it has some disvantage here), a D version without using the GC, a D
> version using the GC, and a Python version.
> 
> Here are the result (Celeron ~2GHz, 1M elements, average from 3 runs):
> 
>        C         C++       D no gc   D gc       D gc dis  Python
> Fill   0.136136  0.142705  0.131238  22.628577  0.242637  12.952816
> Inc    0.025134  0.038768  0.037456   0.050480  0.051545   3.765271
> Total  0.161270  0.181473  0.168694  22.679057  0.294182  16.718087
> 
> Results are in seconds, compiled with gcc/g++/gdc (-O3 -finline, plus
> -frelease for D code). Using phobos (gdc 0.25-20080419-4.1.2-22, with
> debian patches).
> 
> You can see Python is almost twice faster than D doing allocation (and the
> python example has some intentional overhead to make it as close as D code
> as possible, using more Pythonic code could yield better results).

Python used reference counting (~ Python 1.x) in the past, but I think
they switched to a tracing garbage collector in 2.x. Using reference
counting would explain the speedup IMHO. I think any mark and sweep
garbage collector would be somewhat slow in the case of a linked list,
as it has to traverse all elements to determine which memory is live and
which can be freed (so it's O(n)). You'd be probably better off using a
dynamic array here.

Regards,

   Michael