The "no gc" crowd

[Dicebot]

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.