The "no gc" crowd

[Justin Whear]

On Tue, 08 Oct 2013 17:43:45 +0200, ponce wrote:

> Yet with D the situation is different and I feel that criticism is way
> overblown:
> - first of all, few people will have problems with GC in D at all - then
> minimizing allocations can usually solve most of the problems - if it's
> still a problem, the GC can be completely disabled,
> relevant language features avoided, and there will be no GC pause - this
> work of avoiding allocations would happen anyway in a C++
> codebase - I happen to have a job with some hardcore optimized C++
> codebase and couldn't care less that a GC would run provided there is a
> way to minimize GC usage (and there is)

I thought I'd weigh in with my experience with D code that is in 
production.

Over the last couple of years, I've had exactly one bad experience with 
D's garbage collection and it was really bad.  It was also mostly my 
fault.  Our web-fronted API is powered by a pool of persistent worker 
processes written in D.  This worker program had an infrequently-used 
function that built an associative array for every row of data that it 
processed.  I knew this was a bad idea when I wrote it, but it was a 
tricky problem and using an AA was a quick and fairly intuitive way to 
solve it--what's more, it worked just fine for months in production.  At 
some point, however, a user inadvertently found a pathological case that 
caused the function to thrash terribly--whenever we attached to the 
process with GDB, we would almost invariably find it performing a full 
garbage collection.  The process was still running, and would eventually 
deliver a response, but only after being at 100% CPU for ten or twenty 
minutes (as opposed to the <30s time expected).
The function has since been completely rewritten not only to avoid using 
AAs, but with a much better algorithm from a time-complexity point of 
view.  As a "customer" of D I'm a bit torn: should I be impressed by good 
performance we usually got out of such a crappy bit of code or 
disappointed by how terrible the performance became in the pathological 
cases?

As a result of my experience with D over the past few years, I tend to 
write code in two modes:
 - High level language mode: D as a more awesome Python/Ruby/etc.  Built-
in AAs are a godsend.  Doing `arr ~= element` is great!
 - Improved C: avoid heap allocations (and thus GC).  Looks like nice C 
code.

Related to the latter, it would be really nice to be able to prove that a 
section of code makes no heap allocations/GC collections.  At the moment, 
I resort to all-cap comments and occasionally running with breakpoints 
set on the GC functions.

Justin