"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."

Well, I'll argue.
- Garbage collection is not directly related or "reserved" to interpreted languages and, of course, with JIT compilation...
- All sorts of operating system structures are doing special forms of garbage collection.
- There are all sorts of applications (which are often not games) where doing manual, precise memory deallocation is not practical. The only question is to build an ad-hoc garbage collector or use the general-purpose collector from your favorite langage.
- There are some occasions where GC can be faster than manual memory management, because of memory fragmentation, cache thrashing...

Why would you build your own GC instead of improving your allocation mechanisms in manually managed memory? I consider the latter far simpler.

A combination of the two is usually needed to have performance. For example, when you have a lot of similar objects you may want to pre-allocate a memory pool, then the allocation would be fairly simple. De-allocation may not be needed, or if it is, it is done by simply setting a flag in a bitmap.
Garbage collection IS a smart thing to do, as long as you know what happens, and it doesn't pop unexpectedly.