Depending on how many cores you use, what processor you use, and other use cases (e.g. copy-on-write, which is free with RC and super expensive with GC), one of them can be significantly faster than the other. But for a non-specific use case, it has been my experience that they are roughly equivalent.
The place where GC consistently excels is the "no random pauses" - most GCs will occasionally need to stop the world, even when they can mostly do incremental collections. Note that this does not mean they are slower - it is just that the overhead tends to be concentrated in bursts instead of uniformly spread out as in RC.
The place where RC consistently excels is reference loops, and less dependence on implementation robustness.
Just reread, and I got the GC and RC mixed up there (thanks, chancho) too late to edit, so I'll repost a fixed version:
The place where RC consistently excels is the "no random pauses" - most GCs will occasionally need to stop the world, even when they can mostly do incremental collections. Note that this does not mean they are slower - it is just that the overhead tends to be concentrated in bursts instead of uniformly spread out as in RC.
The place where GC consistently excels is reference loops, and less dependence on implementation robustness.
Thanks! I managed to get the two lines confused, not sure how, and it is too late to edit; just posted a correction:
The place where RC consistently excels is the "no random pauses" - most GCs will occasionally need to stop the world, even when they can mostly do incremental collections. Note that this does not mean they are slower - it is just that the overhead tends to be concentrated in bursts instead of uniformly spread out as in RC.
The place where GC consistently excels is reference loops, and less dependence on implementation robustness.
GC may be faster in terms of total amount of time spent managing memory but smart pointers are more predictable. Many domains in which C++ is used are more sensitive to the performance spikes that can arise in GC'd environments than they are to the more expensive but also more spread out cost of managing reference counted objects. Many video game technical directors would choose spending 1ms/30hz frame in memory bookkeeping rather than going 29 frames with no problems only to encounter a 15ms GC hiccup.
Well that depends on the type of pointer -- if you only need the reference till the end of the function, (or when you deconstruct a class) you can get a much more performant implementation.
As for speed, with benchmarking every thing is in the details and while GC can be made to run fast the actual speed depends on the access patterns, the cache and when memory is used (and for how long).
In addition in C++ you can put quite a lot of things on the stack (that is actually how you make a smart-pointer) which is always going to be much, much faster than anything on the heap.
Depending on how many cores you use, what processor you use, and other use cases (e.g. copy-on-write, which is free with RC and super expensive with GC), one of them can be significantly faster than the other. But for a non-specific use case, it has been my experience that they are roughly equivalent.
The place where GC consistently excels is the "no random pauses" - most GCs will occasionally need to stop the world, even when they can mostly do incremental collections. Note that this does not mean they are slower - it is just that the overhead tends to be concentrated in bursts instead of uniformly spread out as in RC.
The place where RC consistently excels is reference loops, and less dependence on implementation robustness.