On Wednesday, 27 July 2016 at 20:42:01 UTC, Guillaume Piolat
wrote:
On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote:
There is the following, which is clever. But if it came down
to having to do this to bypass @nogc, I simply wouldn't use
@nogc.
https://p0nce.github.io/d-idioms/#Bypassing-@nogc
When you have to do it thousands of times throughout your
codebase, then yes, it's that bad.
FWIW I've removed every use of that bypassing (was used for
runtime initialization or semaphores locks).
You can also use emplace/destroy like in:
https://github.com/d-gamedev-team/gfm/blob/master/core/gfm/core/memory.d#L238
The point is though, that I WANT to use the GC. I want the memory
cleaned up for me, and I don't mind little pauses once in a
while. I just don't want careless allocations to happen in
certain performance-sensitive contexts, like per-frame updates.
While working on a past project(C++), I found this little gem:
void draw() {
Font* f = new Font("arial.ttf", 16);
drawText(f, "hello world");
}
As utterly moronic as this seems, this was a real bug that I had
to fix. Our game was literally topping out at 2GB of memory usage
after ~30 seconds and crashing.
Note: it wasn't my code ;)
If that code was written in D with the feature I'm asking for,
draw() would have been marked with @nogc. The person who wrote
the above code would have either had to store the font somewhere
else, or insert a @assumenogc{} section to actually do that. So
it either would not have happened, or would have been much easier
to find.
If you found that your game/app was using too much GC, searching
for "@assumenogc" would likely uncover the cause, as long as your
root classes were annotated correctly. The @assumenogc annotation
would plainly show where allocations were happening that maybe
shouldn't be.
Bit
Bit
