On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:
The key to making D's GC acceptable lies in two factors I
believe.
1. Improve the implementation enough so that you will only be
impacted by GC in extermely low memory or real time
environments.
2. Defer allocation more and more by using ranges and
algorithms more, and trust that compiler optimisations will
make these fast.
The big, big offender I believe for extra allocations is
functions which return objects, rather than functions which
write to output ranges. The single most common occurence of
this is something like this is toString. Instead of writing
this...
string toString() {
// Allocations the user of the library has no control over.
return foo.toString() ~ bar.toString() ~ " something else";
}
I believe you should always, always instead write this.
// I left out the part with different character types.
void writeString(OutputRange)(OutputRange outputRange)
if (isOutputRange!(OutputRange, char)) {
// Allocations controlle by the user of the library,
// this template could appear in a @nogc function.
foo.writeString(outputRange);
bar.writeString(outputRange);
"something else".copy(outputRange);
}
I agreed with this for awhile but following the conversation here
<https://github.com/D-Programming-Language/phobos/pull/2149> I'm
more inclined to think we should be adding lazy versions of
functions where possible rather than versions with OutputRange
parameters. It's more flexible that way and can result in even
fewer allocations than even OutputRange parameters would have
(i.e. you can have chains of lazy operations and only allocate on
the final step, or not at all in some cases).
Laziness isn't appropriate or possible everywhere but it's much
easier to go from lazy to eager than the other way around.
[...]
