>it causes a lot of updates at each pointer 'take' even if it's a read only This isn't required in the read-only case. If you're only borrowing the value, for

>it causes a lot of updates at each pointer 'take' even if it's a read only This isn't required in the read-only case. If you're only borrowing the value, for example, taking a const& in C++ and not holding onto it, then you can cast to the underlying type and use the reference. In Rust you can also just borrow: https://play.integer32.com/?version=stable&mode=debug&edition=2018&gist=f3fc8391316a156065943e35584cdd59 https://play.integer32.com/?version=stable&mode=debug&editio... >trashing caches ARC is usually atomic reference counting. Indeed that will trash caches because it must invalidate the cache line where the reference count lives in other cores whenever it's updated. RC without atomicity won't invalidate cache lines on other cpus. FWIW, GCC has an extension to shared_ptr that doesn't use atomic reference counting: https://gcc.gnu.org/onlinedocs/libstdc++/manual/memory.html#shared_ptr.policy https://gcc.gnu.org/onlinedocs/libstdc++/manual/memory.html#... > Also I've read it causes memory fragmentation Any heap allocations not bound to an arena and not part of a compacting garbage collector is likely to cause memory fragmentation. Stack allocations for example are implicitly compacted. >Also and even more, if ARC is what you think it is, how is it not an implementation of GC? This is a "can submarines swim" type of question and is completely uninteresting (imo). >Finally, if [perl5] outperforms [python], please provide a reference. It doesn't. Not by a long shot. Reference: https://bitbucket.org/ewanhiggs/csv-game/ https://bitbucket.org/ewanhiggs/csv-game/