Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector

[Sean Kelly]

On Wednesday, 8 January 2014 at 19:17:08 UTC, H. S. Teoh wrote:
> On Wed, Jan 08, 2014 at 11:35:19AM +0000, Atila Neves wrote:
>> http://atilanevesoncode.wordpress.com/2014/01/08/adding-java-and-c-to-the-mqtt-benchmarks-or-how-i-learned-to-stop-worrying-and-love-the-garbage-collector/
>
> I have to say, this is also my experience with C++ after I 
> learnt D.
> Writing C++ is just so painful, so time-consuming, and so not 
> rewarding
> for the amount of effort you put into it, that I just can't 
> bring myself
> to write C++ anymore when I have the choice. And manual memory
> management is a big part of that time sink. Which is why I 
> believe that
> a lot of the GC-phobia among the C/C++ folk is misplaced.  I can
> sympathise, though, because coming from a C/C++ background 
> myself, I was
> highly skeptical of GC'd languages, and didn't find it to be a
> particularly appealing aspect of D when I first started 
> learning it.
>
> But as I learned D, I eventually got used to having the GC 
> around, and
> discovered that not only it reduced the number of memory bugs
> dramatically, it also increased my productivity dramatically: I 
> never realized just how much time and effort it took to write 
> code with manual memory management: you constantly have to 
> think about how exactly you're going to be storing your 
> objects, who it's going to get passed to, how to decide who's 
> responsible for freeing it, what's the best strategy for 
> deciding who allocates and who frees. These considerations 
> permeate every aspect of your code, because you need to know 
> whether to
> pass/return an object* to someone, and whether this pointer 
> implies
> transfer of ownership or not, since that determines who's 
> responsible to free it, etc.. Even with C++'s smart pointers, 
> you still have to decide which one to use, and what pitfalls 
> are associated with them (beware of cycles with refcounted 
> pointers, passing auto_ptr to somebody might invalidate it 
> after they return, etc.). It's like income tax: on just about 
> every line of code you write, you have to pay the "memory
> management tax" of extra mental overhead and time spent fixing 
> pointer bugs in order to not get the IRS (Invalid Reference 
> Segfault :P)
> knocking on your shell prompt.

This is what initially drew me to D from C++.  Having a GC is a
huge productivity gain.

> Manual memory management is a LOT of effort, and to be quite 
> honest, unless you're writing an AAA 3D game engine, you don't 
> *need* that last 5% performance improvement that manual memory 
> management *might* gives you. That is, if you get it right. 
> Which most C/C++ coders don't.

The other common case is server apps, since unpredictable delays
can be quite undesirable as well.  Java seems to mostly get
around this by having very mature and capable GCs despite having
a standard library that wants you to churn through memory like
pies at an eating contest.  The best you can do with D so far is
mostly to just not allocate whenever possible, by slicing strings
and such, since scanning can still be costly.  I think there's
still some work to do here, despite loving the GC as a general
feature.