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.
