Linked by Thom Holwerda on Thu 6th Sep 2012 21:32 UTC, submitted by MOS6510
Benchmarks "During the 4th Semester of my studies I wrote a small 3d spaceship deathmatch shooter with the D-Programming language. It was created within 3 Months time and allows multiple players to play deathmatch over local area network. All of the code was written with a garbage collector in mind and made wide usage of the D standard library phobos. After the project was finished I noticed how much time is spend every frame for garbage collection, so I decided to create a version of the game which does not use a GC, to improve performance."
Thread beginning with comment 534182
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: yes... but why?
by Nelson on Fri 7th Sep 2012 04:34 UTC in reply to "RE: yes... but why?"
Member since:

1. The programmer still must handle the memory at some extent in managed languages: he needs to make sure that his unused objects are not being referenced for any reference, he needs to use weak references or he needs to call explicitly to the garbage collector [I remember I had a problem with a behavior similar to a memory leak in C# that occurred because my big array was stored as a 2nd generation object, so the garbage collector did not clean it in a timely fashion; or remember having some "loitering objects" in Java because I forgot to remove some listeners after my frames were closed]."

This is generally a lifetime issue and not really a memory leak, though it can look and quack like one. Especially with event handlers, once the event source itself goes out of scope, any listeners with zero references thereafter will be collected.

So sometimes not unregisering event handlers manifests itself as a memory leak, or sometimes it just lives on a little longer than usual. Makes it quite annoying to track down at times.

2. Though memory is handled automatically by the garbage collector, other resources are not, so, they still need to be managed by the programmer (file handles, registry handles, database connections, window handles, locks, etc. etc.). This inconsistency makes me crazy because you need to call .Dispose() explicitly or need to enclose your code in a "using" statement to free system resources (but not memory). Handling all resources in a good way has the same complexity that handling memory. Using best practices in C++ avoids this problem because any system resource (including memory) is handled automatically and in a deterministic way using the RAII pattern.

If you neglect to dispose of an object, eventually the finalizer is called and the resources are freed. But "using" makes this mostly a non issue.

3. Real good programmers will be productive no matter the language they will code on.

Completely untrue.

All in all, I find dealing with the nuances if even modern c++ to be more if an annoyance than an empowerment.

Reply Parent Score: 4

RE[3]: yes... but why?
by dorin.lazar on Fri 7th Sep 2012 04:38 in reply to "RE[2]: yes... but why?"
dorin.lazar Member since:

All in all, I find dealing with the nuances if even modern c++ to be more if an annoyance than an empowerment.

Try C++11 - with the recent developments I was able to produce a benchmark for an embedded platform, and the development time was equal to the same code being written in C#.

And I'm talking about lambdas and lots of other goodies. Of course, I wasn't doing any Linq but who in their sane mind would use Linq for testing something or for production code? (rethorical, don't answer).

Reply Parent Score: 1