@gc attribute for bypassign @nogc

[Lodovico Giaretta via Digitalmars-d]

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.

Well, here in my opinion there's the wrong attitude of profiling 
only when it becomes necessary (i.e. the app is slow or uses too 
much ram). This is wrong. You should profile before this happens; 
you should profile to see if the time/memory is spent in the 
parts of the application that should spend it and you should 
profile whenever you care about making good code and not just 
"code that works". You should profile while you add features, to 
see their impact on the overall performance. Profiling at the 
end, when you have a 100K LOC codebase deployed, because a user 
ran out of memory is too late: too late to allow to easily spot 
the problem and too late to think an alternative 
approach/algorithm/design, instead of just patching the problem.