Garbage Collector?

[Mike Parker via Digitalmars-d]

On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:

>> so I'll reply:
>> Expanding the continuous memory region a dynamic array 
>> consists of (possibly moving it) once it overflows has 
>> absolutely nothing to do with the GC, or even the language, 
>> it's how the abstract data type "dynamic array" is defined. D 
>> just does this transparently for you by default. If you 
>> already know the exact or maximum size, you can allocate 
>> *once* (not 6 times) using `new` and `.reserve` respectively 
>> *before* entering the loop, like that article explains in 
>> depth.
>
> You seem to be missing the fact that i pointed this out. The 
> fact that the GC might have done up to 6 collection rounds in 
> that loop is "ludicrous".

How is it ludicrous? The fact that you know the GC will only run 
during an allocation, and only if it needs to, allows you to 
control when those opportunities to collect arise. That's a much 
more palatable situation than if it were sitting in the 
background, constantly checking if it needs to collect, then 
doing so without any input from you. There, you'd have no control 
at all.

In the context of an actual program, the example would only have 
made 6 collections if you were putting putting heavy pressure on 
the GC heap, which is an extremely naive way of programming for 
anyone concerned about performance. D allows you several options 
to relieve that pressure and assert some control over when the GC 
can run. Even in a non-GC language, you wouldn't be allocating 
like that in a performance-critical loop -- you would preallocate 
before you entered the loop.