John Carmack applauds D's pure attribute

[Walter Bright]

On 3/6/2012 4:27 AM, Manu wrote:
> On 26 February 2012 00:55, Walter Bright <newshound2 at 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.