gc vs explicit

[Walter Bright]

zz wrote:
> Walter Bright wrote:
>> zz wrote:
>>
>>>  From my point of view these tests are not really nessesary on my 
>>> side since I still continue using D and I belive that someday the 
>>> memory stuff will be optimized.
>>
>>
>> One thing that is happening is that the C++ code allocates memory, it 
>> never frees it. The same with the D code.
> 
> Not until it's out of scope (in this case main).

True, but it doesn't free any memory inside the loop.

>> What happens with a garbage collector is it gets new chunks of memory 
>> from the operating system as it needs it. But before it does, it runs 
>> a collection cycle.
> 
> Would something like dlmalloc by Doug Lea make a difference in D, 
> someone suggested trying it out so I tested it using DMC on some C code 
> and there was a big difference the two compiled versions (Numbers are 
> below and I was supprised).

You can call any C function from D, so if you want to explicitly manage 
memory using dlmalloc, that is certainly possible. D allows overriding 
new/delete on a per class/per struct basis, but such won't be garbage 
collected if you do so.

>> So in the D version, it will be running probably several collection 
>> cycles (accomplishing nothing), while the C++ version does not. This 
>> will make the gc version slower.
>>
>> To get better numbers, one can add calls to gc.disable() and 
>> gc.enable() to tell the gc that there is no point to running a 
>> collection cycle for this section of code.
> 
> The above is something that, i'll not do (In DMC i can get better 
> numbers by just changing my allocator how can I go about it in D).

I'm not sure why you wouldn't want to do it, it is much more localized 
in effect than swapping out global operators new/delete.

The gc in D is pluggable, but nobody has written a different one to plug 
  in yet.