Slicing works, it just requires more care. GC makes slicing work pretty much
automatically, though you can end up with severe memory bloat.
On Mar 6, 2012, at 6:25 PM, Walter Bright <newshou...@digitalmars.com> wrote:
> 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.
