What are the worst parts of D?

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 10 20:39:08 PDT 2014


On Friday, 10 October 2014 at 08:45:38 UTC, Marc Schütz wrote:
>> Yes and quite notably so as GC.malloc can potentially trigger 
>> collection. With concurrent GC collection is not a disaster 
>> but it still affects the latency and should be avoided.
>
> Is it just the potentially triggered collection, or is the 
> actual allocation+deallocation too expensive?

collection - for sure.
allocation+deallocation - maybe, I have never measured it. It is 
surely slower than not allocating at all though.

> Because the effects of the former can of course be reduced 
> greatly by tweaking the GC to not collect every time the heap 
> needs to grow, at the cost of slightly more memory consumption.

This is likely to work better but still will be slower than our 
current approach because of tracking many small objects. Though 
of course it is just speculation until RC stuff is implemented 
for experiments.

>>> Also let's note that extending existing chunks may result in 
>>> new allocations.
>>
>> Yes. But as those chunks never get free'd it comes to O(1) 
>> allocation count over process lifetime with most allocations 
>> happening during program startup / warmup.
>
> Hmm... but shouldn't this just as well apply to the temporary 
> allocations? After some warming up phase, the available space 
> on the heap should be large enough that all further temporary 
> allocations can be satisfied without growing the heap.

I am not speaking about O(1) internal heap increases but O(1) 
GC.malloc calls
Typical pattern is to encapsulate "temporary" buffer with the 
algorithm in a single class object and never release it, reusing 
with new incoming requests (wiping the buffer data each time). 
Such buffer quickly gets to the point where it is large enough to 
contain all algorithm temporaries for a single request and never 
touches GC from there.

In a well-written program which follows such pattern there are 
close to zero temporaries and GC only manages more persistent 
entities like cache elements.


More information about the Digitalmars-d mailing list