On Mon, 06 Apr 2015 18:06:59 GMT, Dato wrote:
I see. I guess those classes are similar to smart pointers. Just to make sure, is D's GC so bad? I can use RefCounted and FreeListRef, but what about vibe's internal implementation? We are going to have several thousand small requests per second and GC should also be an issue for vibe's internal allocations/calls no? Currently, our C# implementation handles ~7k requests per second without caching on a single server. According to our (dirty work) benchmarks, the system should perform at least 35% better when ported to GDC, but we didn't check GC to be honest...
Thanks again :)
A small note on this topic: D is a language that evolve pretty fast. It doesn't mean breaking changes (those are quite rare nowadays), but a new version usually brings a lot of improvements / bugfixes, both for the compiler and the standard library.
GDC and LDC use DMD's frontend code (what 'parses' the language), but they have to port it every time a new version is released.
At the moment, latest LDC use the frontend of DMD 2.066.1, and GDC use the frontend of 2.065.0.
The problem is, the library evolve as fast as the frontend, and depends on it. So with a compiler that supports 2.065, you'll get the library as it was with 2.065.
The two mains issue I can see for performance critical systems is:
- lack of the
@nogcattribute (introduced in 2.066.0: http://dlang.org/changelog.html#nogc-attribute), because it also led to a lot of allocations being removed from Phobos. - A very annoying and longstanding bug where struct destructor allocated on the GC heap didn't had their destructor called was fixed in 2.067 ( http://dlang.org/changelog.html#heap-struct-destructors ).
So I'll suggest you to keep an eye on LDC, which produce code superior to DMD, but isn't as far behind in term of frontend as GDC is ATM (there's also the possibility that GDC is ported to 2.066.x / 2.067.x, but I'm not aware of any plan ATM).