On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
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.
If @assumegc has to be manually checked to see if it is
over-allocating whenever the application is going out of memory,
then it is no more useful than running the gc-profiler when the
application is over-allocating. The profiler is even better,
because with @assumegc you have to check ALL marked functions to
find the leaking one, while the gc-profiler would just put it on
top of the report, making your job easier. So IMHO we already
have an instrument to solve these problems.
