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

Atila Neves atila.neves at gmail.com
Wed Jan 8 16:46:48 PST 2014


> No, this expierence is not only based of this. I observed 
> multiple discussions on the newsgroup, where turning off the GC 
> would speed up the program by factor 3. The most recent one was

The GC doesn't even show up in the profiler for this/my use case. 
The one optimisation I did to avoid allocations increased 
performance by all of 5%. It really depends on the use case, and 
I don't think assuming a factor of 3 is advisable.

> That is another common argument of pro GC people I have never 
> seen in partice yet. Meaning, I never seen a case where freeing 
> a tree of objects would cause a significant enough slowdown. I 
> however saw lots of cases where a garbage collection caused a 
> significant slowdown.

Well, if I wasn't aware of allocation I wouldn't have done the 
optimisation mentioned above, so it's a good point.

As far as slowdown happening with manual memory management, in 
certain cases cleaning up reference counted smart pointers can 
cause as much of a slowdown as a GC kicking in. This isn't my 
opinion though, there are data to that effect. Again, it depends 
on the use case.

> Still it only solves half the problem.

Maybe in Java. In D at least we have struct destructors for other 
resources.

> It was never intended to. I just wanted to make the point, that 
> even if you want, you can't avoid C++.

A fair point. I think what we're saying is not that we won't ever 
write C++ again, but that we won't write it again if given the 
choice and if another language (not necessarily D) is also a good 
fit.

I'd be surprised if I wasn't still writing / refactoring / 
debugging C++ code a few decades for now. I don't want to write C 
again ever, but I know I'll have to.

> I fully agree here. Still when choosing a programming language 
> you also have to pick one that all programmers on the team can 
> and want to use. I fear that the D metaprogramming capabilities 
> will scare of quite a few programmers because it seems to 
> complicated to them. (Its really the same with C++ 
> metaprogramming. Its syntactically ugly and verbose, but gets 
> the job done, and is not so complicated if you are familiar 
> with the most important concepts).

I disagree wholeheartedly. It's a _lot_ more complicated in C++. 
D can also do more than C++, with far saner syntax.



More information about the Digitalmars-d mailing list