2011/4/22 Timon Gehr <timon.g...@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.