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

[Walter Bright]

On 1/8/2014 10:11 PM, Manu wrote:
> On 9 January 2014 13:08, Walter Bright <newshound2 at digitalmars.com
> <mailto:newshound2 at digitalmars.com>> wrote:
>
>     On 1/8/2014 12:23 PM, Benjamin Thaut wrote:
>
>         Additionaly programming with a GC often leads to a lot more allocations,
>
>
>     I believe that this is incorrect. Using GC leads to fewer allocations,
>     because you do not have to make extra copies just so it's clear who owns the
>     allocations.
>
>
> You're making a keen assumption here that C programmers use STL.

My observation has nothing to do with the STL, nor does it have anything to do 
with how well the GC is implemented. Also, neither smart pointers nor ARC 
resolve the excessive copying problem as I described it.

I've been coding in C for 15-20 years before the STL, and the problem of 
excessive copying is a significant source of slowdown for C code.

Consider this C code:

char* cat(char* s1, char* s2) {
     size_t len1 = s1 ? strlen(s1) : 0;
     size_t len2 = s2 ? strlen(s2) : 0;
     char* s = (char*)malloc(len1 + len2 + 1);
     assert(s);
     memcpy(s, s1, len1);
     memcpy(s + len1, s2, len2);
     s[len1 + len2] = 0;
     return s;
}

Now consider D code:

string cat(string s1, string s2) {
     return s1 ~ s2;
}

I can call cat with:

     cat("hello", null);

and it works without copying in D, it just returns s1. In C, I gotta copy, ALWAYS.

(C's strings being 0 terminated also forces much extra copying, but that's 
another topic.)

The point is, no matter how slow the GC is relative to malloc, not allocating is 
faster than allocating, and a GC can greatly reduce the amount of alloc/copy 
going on.

The reason that Java does excessive amounts of allocation is because Java 
doesn't have value types, not because Java has a GC.