On 3/6/2012 4:27 AM, Manu wrote:
On 26 February 2012 00:55, Walter Bright <newshou...@digitalmars.com
Most straight up GC vs malloc/free benchmarks miss something crucial. A GC
allows one to do substantially *fewer* allocations. It's a lot faster to not
allocate than to allocate.
Do you really think that's true?
Yes.
Are there any statistics to support that?
No, just my experience using both.
Consider strings. In C, I'd often have a function that returns a string. The
caller then (eventually) free's it. That means the string must have been
allocated by malloc. That means that if I want to:
return "foo";
I have to replace it with:
return strdup("foo");
It means I can't do the "small string" optimization. It means I cannot return
the tail of some other string. I cannot return a malloc'd string that anything
else points to. I *must* return a *unique* malloc'd string.
This carries into a lot of data structures, and means lots of extra allocations.
Next problem: I can't do array slicing. I have to make copies instead.
You suggested using ref counting. That's only a partial solution. Setting aside
all the problems of getting it right, consider getting a stream of input from a
user. With GC, you can slice it and store those slices in a symbol table - no
allocations at all. No chance of that without a GC, even with ref counting.
