On Friday, 12 October 2018 at 21:39:13 UTC, Atila Neves wrote:
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.
Then five years later, try and hunt down that mysterious heap
corruption. Caused by some destructor calling into buggy
third-party code. Didn't want to think about that one either?
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.
There is no "sometimes" here. You're writing programs for
specific machines. All. The. Time.
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.
All code is performance sensitive. Whoever invented that
distinction should be publicly humiliated. If it's not speed,
it's power consumption. Or memory. Or I/O. "Not thinking" about
any of that means you're treating your power champion horse as if
it was a one-legged pony.
Advocating the "not thinking" approach makes you an outright evil
person.
