On Thursday, 28 July 2016 at 16:58:14 UTC, default0 wrote:
On Thursday, 28 July 2016 at 16:45:05 UTC, bitwise wrote:
On Thursday, 28 July 2016 at 16:15:04 UTC, Guillaume Piolat
wrote:
On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote:
It's not about running out of memory. It's a performance
issue.
Example: In the following class, it would be perfectly fine,
and even expected to allocate in start() but not in
update(). This is because start() gets called once on object
initialization, but update() would get called every frame.
Vladimir implemented counting in -profile=gc, it gives you
the number of allocations and the amount allocated for each
allocation point.
I'm not sure if this point is meant to be for or against what
I'm suggesting, but still, I'm thinking in terms of
*proactively* writing efficient code, not allowing an app get
to the point where you need to run a profiler.
The situation is similar to using @safe. You *could* just
write code however you want, wait until it crashes, then try
to find the problem using Valgrind or something, but that's
bad for obvious reasons.
Bit
Just my 2 cents on naming: what you want sounds a lot more like
@warngc than @assumenogc or whatever was floating around
before. What such an attribute should do and if its worth
implementing is hard to figure out, though. Presumably you'd
have your update() method marked @warngc but then how is the
compiler supposed to know that an allocation like this:
class A {
void update() @warngc {
if(rareCondition()) {
// something that allocates
}
}
}
is perfectly fine, but something like this
class B {
void update() @warngc {
if(almostAlwaysTrue()) {
// something that allocates
}
}
}
is not?
That issue aside, what exactly do you envision the compiler to
tell you (examples of error messages and code patterns it
should detect, examples of code patterns that it should NOT
detect and are fine) incase it automagically finds problematic
code?
I'm having trouble putting a thumb on what you want following
this thread, because what you are describing feels a bit vague
to me.
I think you're complicating the issue quite a bit here.
It's very simple:
@nogc { /* in this scope, compiler disallows GC allocations. */ }
@nogc {
@assumenogc { /* here, GC allocations are allowed */ }
}
@assumenogc would simply reverse the effects of the @nogc flag on
a given scope.
So @nogc could be applied to performance critical scopes, as it
is now. The exception would be, that if I as a programmer knew
that I was only making a small one-time allocation, and that the
GC was still enabled, I could do so by surrounding the allocation
with @assumenogc.
Bit
