On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov
wrote:
On Friday, 12 October 2018 at 19:55:02 UTC, Nicholas Wilson
wrote:
Freeing your mind and the codebase of having to deal with
memory leaves it in an easier place to deal with the less
common higher impact leaks: file descriptors, sockets,
database handles ect. (this is like chopping down the forest
so you can see the trees you care about ;) ).
That's done first and foremost by stripping out unnecessary
allocations, not by writing "new" every other line and closing
your eyes.
D isn't Java. If you can, put your data on the stack. If you
can't, `new` away and don't think about it. The chances you'll
have to optimise the code are not high. If you do, the chances
that the GC allocations are the problem are also not high. If the
profiler shows they are... then remove those allocations.
I mean come on, it's 2018. We're writing code for multi-core
and multi-processor systems with complex memory interaction.
Sometimes we are. Other times it's a 50 line script.
Precisely where in memory your data is, how it got there and
how it's laid out should be bread and butter of any D
programmer.
Of any D programmer writing code that's performance sensitive.
It's true that it isn't critical for one-off scripts, but so
is deallocation.
We'll agree to disagree.
Saying stuff like "do more with GC" is just outright harmful.
Disagreement yet again.
