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
