Linus with some good observations on garbage collection

[Ulrik Mikaelsson]

2011/4/22 Timon Gehr <timon.gehr at gmx.ch>:
> That is only a problem if the reference count of that resource changes at a very
> high frequency. The described problem also implies that the threads would not need
> any form of synchronization for the data (otherwise the reference count certainly
> would not be a bottleneck.)
....
> Michael Stover wrote:
>> I'd like to say "were proved" rather than "are believed", but I don't actually
> know where to go for such evidence.
>>  However, I do believe many scripting languages, such as python, eventually
> ditched the reference counting technique for
>> generational, and Java has very fast GC, so I am inclined to believe those
> real-life solutions than Linus.
>
> Well, the GC may be fast when compared to other GCs, but it has to be designed to
> run on general data whose reference structure can be arbitrary. Often, the
> objects/references have a somewhat specialized structure that a smart programmer
> can exploit, especially if the references point to private data. But that only
> matters if performance is of prime interest, and the gains may be not very big.

All in all, I think the best approach is a pragmatic one, where
different types of resources can be handled according to different
schemes.

I.E. default to GC-manage everything. After profiling, determining
what resources are mostly used, and where, optimize allocation for
those resources, preferably to scoped allocation, or if not possible,
reference-counted.

Premature optimization is a root of much evil, for instance, the
malloc-paranoid might very well resort to abuse of struct:s, leading
either to lots of manual pointers, or excessive memory copying.

Incidentally, this was the main thing that attracted me to D. Be
lazy/productive where performance doesn't matter much, and focus
optimization on where it does.