gc vs explicit

Dave Dave_member at pathlink.com
Fri Dec 8 10:20:44 PST 2006


Sean Kelly wrote:
> zz wrote:
>> Dave wrote:
>>> 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).
>>>>
>>>
>>> With that in mind, I wrapped your original code in a loop for 10 
>>> iterations and decreased the inner loop to 100000.
>>>
>>> C++ (NedAlloc):
>>> Total Element count: 1000000
>>> 5.438000
>>>
>>> D:
>>> Total Element count: 1000000
>>> 1.360000
>>>
>> Cant' argue with that:
>> In this case D is faster I get:
>> C++ NedAlloc = 2.859
>> D = 1.421
>>
>> But if you leave the original count and put in the outer loop for 10, 
>> D's performance becomes really bad.
>>
>> c++ (NedMalloc) = 00:26.796
>> D = 02:23.375
> 
> Try explicitly calling _gc.fullCollect() between iterations of the inner 
> loop, and disabling the GC explicitly there.  Manipulation of the GC for 
> performance-critical areas is an important and intentional feature.
> 

With that in mind... What if some of the GC API were built-in to the language? This could be one of 
those areas that would set D apart as a lower-level, performance orientated language. If a GC 
implementation didn't support something, it would be stubbed for portability. Likewise anything not 
covered explicitly by a built-in could be covered by an import.

Specifically:

gcFullCollect()
gcGenCollect()
gcDisable()
gcEnable()

or some such.

?

> 
> Sean



More information about the Digitalmars-d mailing list