Gregory Peele ARA/CFD escribió:
I agree that the internal GC approach could potentially have the same performance benefits as a traditional GC for the workload I described, especially with some cleverness in lock-free algorithms to handle multithreading. I assume it would probably perform quite a bit better actually, since it doesn't have to solve the finalization problem. As mentioned, so would a well written pool allocator - these are just two different approaches to amortizing memory allocation and deallocation costs.
Of course, an internal GC or any pool allocator techniques I've heard of don't help with the huge developer and maintainer cost of correctly implementing pointer ownership rules for complex cyclical data structures without paying the CPU and memory cost of thread-safe cycle-safe reference counting. I spent far more time solving memory leaks, dangling pointers, and invalid memory dereferences than I did implementing, testing, and correcting actual geometry logic for my Delaunay triangulation package, and my only used resource was memory so I didn't need deterministic finalization. Increasing developer productivity when used for the right task is where a traditional GC really shines, I think.
Hi Gregory, I agree with you that alledged benefits of GCs have to be sought in the realm of increased productivity --not that I like GCs, but that's another matter. I just wanted to point out that performance cannot possibly be presented as an advantage of garbage collection vs. RAII. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo