D for Game Development

[Benjamin Thaut via Digitalmars-d]

On Wednesday, 5 August 2015 at 16:44:03 UTC, jmh530 wrote:
> On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut 
> wrote:
>>
>> Regarding D's GC and Games written in D you can also take a 
>> look at a old project of mine and the results that came out of 
>> it.
>>
>> http://3d.benjamin-thaut.de/?p=20
>
> Towards the end you list some performance and memory leaking 
> issues in D. Have you seen improvement in these areas?


- Comparision of TypeInfo objects in druntime is done by building 
two strings and then comparing those two strings. This will 
always leak memory and do a lot of unneccesary allocations which 
are a performance bottleneck. I reworte the comparison so it does 
not allocate a single byte.

I did a pull request to improve this once, but it was rejected. 
So this issue still remains. Comparing two type info objects 
still produces garbage.

- Calls to the druntime invariant handler are emitted in release 
build also and there is no way to turn them off. Even if the 
class does not have any invariants the invariant handler will 
always be called, walk the class hirarchy and generate multiple 
cache misses without actually doing anything.

Afaik this has been fixed.

- The new statement will not free any memory if the constructor 
throws a exception. So you are forced to replace both the new and 
the delete statement. But you can not replace the new statement 
with similar nice syntax especially for inner classes and arrays.

This issue still remains, although might improve soon with 
std.allocator. The language is not designed to make it possible 
for new/delete to be replaced in a nice way so most likely

new int[3] will become allocator.makeArray!int(3)

- Inlining of DMD. Inlining of DMD seems to be very minimal. Most 
of my overloaded operators are not inlined by dmd at all.

This somewhat improved, especially with pragma(inline) but dmd is 
still really bad at inlining and I still can't compile all my 
projects with the -inline switch because dmd produces invalid 
function calls if I do so. And don't tell me to use a different 
compiler, on windows the only viable option still is dmd. Gdc for 
windows is no longer maintained and ldc is not there yet (but 
might be soon).

- Array literals. They always allocate, even if they don’t have 
to. For example when asiging to a fixed size array, or when 
passing to a function with a scope parameter.

This greatly improved. Thanks to Kenji you can now have non 
allocating array literals.

- D-Style variadic functions. Same as array literals, because 
internaly they are rewrote to one. Especially for these kind of 
functions I don’t see any reason why they should allocate on the 
heap.

I'm not sure about this one, I would have to investigate.

Kind Regards
Benjamin Thaut