[Gc] conclusions (benchmarking, compilation, failures)
scholz at scriptolutions.com
Thu Apr 26 19:02:17 PDT 2007
Friday, April 27, 2007, 2:11:44 AM, you wrote:
AM> C/C++ with multithreaded libgc: 1200 ms
AM> C/C++ with simple allocator(*): 300 ms
AM> 4) (*) using a simple allocator which incremented a pointer to an array
AM> of 256 MB, the test time drop to 300 ms. That's probably the fastest
AM> allocation possible, and it shows that it is a shame that we can't have
AM> native applications with a copying collector.
Looks like libgc is pretty good. If it is only 4 times slower then the
easiest and fastest possible case then it is very usefull in real
I must say that after using the gc for a few years in my app, i worry
anything else more then the garbage collectors runtime. But this is
only after i added code to NULLify all non used items (at least where
it is easy to do so). Only the lack of good thread local allocator
is a thing that still should come soon.
So my advise: Don't worry to much about an artifical benchmark.
Lothar Scholz mailto:scholz at scriptolutions.com
More information about the Gc