OSNews thread here degenerates into GC vs not

[Pragma]

Mike Parker wrote:
> I haven't used D extensively enough to know 
> what "coding to the GC" means for the current implementations, but 
> developers who do understand it should be able to avoid the lion's share 
> of issues.

FWIW, the worst I've run into with the D GC was by aggressive use of opCat:

uint[] arr;
for(uint i=0; i<65535; i++){
   arr ~= i;
}

Code like this was causing a good amount of memory to be allocated, and 
then subsequently abandoned - a very small fraction of the heap was 
actually in use.  After I had some help with the guys out on #D to try 
and track this down, we found that the internal array allocator that was 
the culprit.

The "heap bloat" was easily circumvented with a struct that pretends to 
be an array, and uses a more conservative re-allocation algorithm by way 
of using a less conservative *pre*-allocation algorithm.  It wasn't 
rocket-science or anything - anyone who understands what CoW means could 
hardly call it surprising.

So in short: In my experience, GC issues in D aren't uncommon, but then 
"coding to the GC" is pretty easy to do with some very rudimentary 
analysis.  IMO, wise use of smart datatypes, scope() and delete pretty 
much cover the rest of the places where the GC is too lazy/slow/dumb to 
do the job. :)

-- 
- EricAnderton at yahoo