Faster Virtual Method Dispatch

[Sean Kelly]

BCS wrote:
> 
> A bad GC will definitely make for bad performance. And any GC will be slower
> than an optimum malloc/free solution. However (and I’m still undecided on this
> one) I think the argument is that in any non trivial project, manually freeing
> all of the memory without any memory leaks or axing something to soon would
> require more overhead than using GC. The trade-off is not in the freeing time
> but in the can-I-free-this check.

I believe this is indeed the common argument.  In C++, smart pointers 
have become a very popular way to manage memory, and while smart 
pointers are technically a garbage collection strategy, I think they 
aren't considered as such here.  In any case, the cost comes from 
updating the reference count, not from the malloc/free, as the updates 
must typically be performed atomically.  That said, an accurate 
performance comparison between GC and manual memory management is 
extremely difficult because implementation details and use strategies 
have a tremendous impact on results.  For anyone interested, there's 
been an extensive argu- um, dialog on the topic recently on 
comp.lang.c++.moderated titled "Can GC be benifical":

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/84253d37f970dd2b/#


Sean