The "no gc" crowd

[Peter Alexander]

On Tuesday, 8 October 2013 at 20:44:55 UTC, Dicebot wrote:
> On Tuesday, 8 October 2013 at 19:38:22 UTC, Peter Alexander 
> wrote:
>> Making sure your code doesn't allocate isn't that difficult.
>
> What would you use for that? It is not difficult, it is 
> unnecessary (and considerably) time-consuming.

Just learn where allocations occur and avoid them during 
development. This leaves you only with accidental or otherwise 
unexpected allocations.

For the accidental allocations, these will come up during 
profiling (which is done anyway in a performance sensitive 
program). The profiler gives you the call stack so these are 
trivial to spot and remove. There are also several other ways to 
spot allocations (modify druntime to log on allocation, set a 
breakpoint in the GC using a debugger, etc.) although I don't do 
these.

You say it is time consuming. In my experience it isn't. General 
profiling and performance tuning are more time consuming.

You may argue that profiling won't always catch accidental 
allocations due to test coverage. This is true, but then @nogc is 
only a partial fix to this anyway. It will catch GC allocations, 
but what about accidental calls to malloc, mmap, or maybe an 
accidental IO call due to some logging you forgot to remove. GC 
allocations are just one class of performance problems, there are 
many more and I hope we don't have to add attributes for them all.