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 534378
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: GC is for scripting
by tanzam75 on Sat 8th Sep 2012 17:36 UTC in reply to "RE[3]: GC is for scripting"
tanzam75
Member since:
2011-05-19

If so, then you're making your own head explode. Because I never wrote that.

I pointed out that the student was complaining about "precisely the scenario" that performs better under GC than without GC, and then said that "no wonder" he ran into problems when he took out the GC.

In other words, you will write your code differently if you have a GC, compared to if you do not have a GC. If you have a GC, you do not worry too much about short-lived objects, but worry a great deal about medium-lived objects. If you do not have a GC, then you do not worry too much about medium-lived objects, but must take care to avoid excessive overhead from constructing and destructing short-lived objects.

Since the student directly ported code that assumes a GC, it is not surprising that he ran into problems when he took out the GC. Indeed, by tailoring the code to the non-GC platform, he was able to eliminate the performance penalty.

It's puzzling how you make the leap from that to the straw man that "high performance and non-leaking code can only be achieved by using a GC."

Edited 2012-09-08 17:38 UTC

Reply Parent Score: 3

RE[5]: GC is for scripting
by Alfman on Sat 8th Sep 2012 18:56 in reply to "RE[4]: GC is for scripting"
Alfman Member since:
2011-01-28

tanzam75,

"If you have a GC, you do not worry too much about short-lived objects, but worry a great deal about medium-lived objects. If you do not have a GC, then you do not worry too much about medium-lived objects, but must take care to avoid excessive overhead from constructing and destructing short-lived objects."

I still don't think it's safe to assume these generalisations are accurate without benchmarking them in an application.

At the very least you need to qualify the quoted statement for objects which are on the heap, since objects which are on the stack won't suffer any heap allocation overhead. In a GC language, it can be difficult for the compiler to determine whether an object can be stored on the stack or heap since it doesn't know what other functions will do with pointers. In a non-GC language, it's possible to allocate objects on the stack and let the object destroy itself as it goes out of scope, which is free.

I'm not trying to promote one side over the other, but the issue is much more complex than can be surmised by generalisations. Programmers just have to benchmark their own code.

Reply Parent Score: 2

RE[6]: GC is for scripting
by tanzam75 on Sat 8th Sep 2012 21:55 in reply to "RE[5]: GC is for scripting"
tanzam75 Member since:
2011-05-19

I still don't think it's safe to assume these generalisations are accurate without benchmarking them in an application.


Of course, benchmarking is always the first step in attacking performance problems. Every problem is unique.

That does not mean that we can't give rules of thumb. They may not always be true in every scenario, but they give you a starting point. They tell you what to pay attention to during the benchmarks, and what tweaks to try.

Reply Parent Score: 2

RE[6]: GC is for scripting
by sakeniwefu on Sun 9th Sep 2012 02:56 in reply to "RE[5]: GC is for scripting"
sakeniwefu Member since:
2008-02-26


"If you have a GC, you do not worry too much about short-lived objects, but worry a great deal about medium-lived objects. If you do not have a GC, then you do not worry too much about medium-lived objects, but must take care to avoid excessive overhead from constructing and destructing short-lived objects."

I still don't think it's safe to assume these generalisations are accurate without benchmarking them in an application.


Benchmark, benchmark, and when you've established that there isn't any possible bottleneck other than memory allocation, then it still isn't the memory allocation system.

Some time ago, I designed and implemented an abstraction layer for an embedded OS and when the app it was serving was reported as being too slow by the customers my system allocator wrapper was singled out as the problem by the "profiler".

This was in a world of custom prematurely optimized everything. So my decision to keep it simple was met with little sympathy.

So, I rewrote it with a custom memory management algorithm to the point allocation and release were barely slower on average than a void (library) function call.

Guess what? It still was the bottleneck.

Some good old printf profiling revealed that the OOP client application was hitting it like crazy.

Classic allocation, Reference Counting, Garbage Collection, it wouldn't have made a difference.

The problem I see in all of GC, RAII(for system memory) or ARC is that they encourage the everything is an object mentality. And that mentality generally turns into programs that hit the allocator way too much.

Reply Parent Score: 2