On Tuesday, 8 October 2013 at 22:02:07 UTC, Peter Alexander wrote:
Just learn where allocations occur and avoid them during
development. This leaves you only with accidental or otherwise
unexpected allocations.
D is not expected to be a single man project language, isn't it?
As I have already said, this implies spending plenty of time on
careful reviewing of something that compiler can detect.
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.
1) Profiling is not always possible.
2) Profiling is considerably more time-consuming than getting
compiler error.
Time spent on this increases with team size and amount of
unexperienced developers in team.
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.
That is why I am askign about @noheap, not about @nogc - GC here
is a just a side thing that makes hidden allocations easier.
Though question about defining full set of possible system-wide
allocation sources is good one and I don't have any reasonable
answer for this.
