I didn't know this, that's pretty cool. Definitely more manual than what Swift is trying to do with RC elision since you have to then deal with runtimes, but also, I'd imagine much more performant due to a finer-grained nature.
Yes, and beyond that, you also have the Rc<T> vs Arc<T> split, so if you're not doing multi-threaded, it's not even an atomic increment/decrement.
That said, this is just my intuition here, I've never seen a good benchmark trying to do the comparison, so I don't want to over sell it either. But a lot of times, it's like, "okay I have four threads so I need the refcount to go to four" and then it's just using normal references to actually use the value inside.
Rc is cheap to the point of free unless it frees - it’s literally just an addition or subtraction with no data dependency in the path. Your CPU can do > 6 billion of these per second on a 6Ghz CPU (if I recall correctly you could do 3 per clock cycle in a micro benchmark due to out-of-order but at a minimum you should be able to do 1 per cycle).
Arc is quite expensive, particularly on x86 because of its memory model. You can maybe do a few million of them per second. But as you said, you shouldn’t be incrementing ownership once you’ve sent it to a new thread and instead using references directly or using something Rc-like to track the lifetime (i.e. when the current thread’s Rc count hits 0, release your Arc reference).
