> From what I've seen the ref counting can cause a big performance hit.

Apple has been writing OS components in Swift for a while now. It certainly doesn't seem to be producing the performance issues we saw when Google attempted to write components for Fuchsia in Go or Microsoft's effort to create new features for Longhorn in .NET.

But it's mostly replacing Objective-C code which was already not particularly fast – as opposed to the C++ or C code used more often in performance- or memory-sensitive areas.

My experience with Swift is somewhat limited, because every time I've tried to use it, I've run into glaring performance issues and had to switch language. It might be reasonably performant compared to Go or .NET, but it's nothing like Rust.

What kind of stuff were you doing in Swift to notice performance issues? I've been developing macOS and iOS apps for a while now and it doesn't seem much slower than Objective-C.

Was probably due to FFI for Go I'd assume.

Do you have a reference somewhere I can read up?

It was discussed here when they decided their networking stack in Go would need to be rewritten for performance reasons, and banned the future use of Go for Fuchsia system components.

https://news.ycombinator.com/item?id=22409838

Reference counting is slow because it has an additional increment/decrement operator on each lifetime of a scope.

Add a little bit of salt to insult you need it to be atomic if you want it to run on SMP. This means for each time you have create/release the lifetime of an object you will make a lot of memory barriers, and create a lot of cache contention.

But in practice the overhead is actually nought, and most of the time you rather deal with I/O bound problem more than an additional atomic increment operation. Modern processor is fast enough to deal with them in few cycles in around the order of 10 nanoseconds

> Reference counting is slow because it has an additional increment/decrement operator on each lifetime of a scope.

On Apple Silicon this particular use case saw a large optimization compared to Intel.

> fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1

Swift's refcounting is atomic (as is objc's). As long as you're not under contention most benchmarks I've seen show negligible overhead (from the addition of atomicity, the refcount overhead is still there) for uncontended access. But IME if you do have many threads walking the same data structure you end up spending stupid amounts of time fighting the refcounting. This applies even if the data structure is immutable and has guaranteed lifetime as swift's type system doesn't seem to allow that to be expressed, and as a result it seems to do a lot of ref churn we'd consider unnecessary.

IME Swift’s refcounting is either incredibly inconsequential or a dealbreaker, with very little in between. They’ve done a very good job of optimizing it to the point where it’s barely measurable even in perf sensitive code… until you hit the scenarios where it completely murders performance and there’s nothing you can do about it.

Hopefully the upcoming ownership functional will help in those cases.

* * *

On apple hardware, uncontended refcounting (swift or objc) has the same perf as non-atomic refcounting. The cost exists, but it isn't terrible, once there's contention between threads the perf drops through the floor. The real killer is there are a bunch of places where the swift evaluation model means they're forced to ref churn, which comes up 100% typical workloads like the million triangle objects in my swift raytracer, all being hit by numerous threads :D

Apple has always been preferential to reference counting (see Objective C) and it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it.

> it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it

According to information released when the M1 came out: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1

It's good to reduce the cache hot best case time of course but isnt the more fundamental sin of RC in the extra read/write memory traffic, cache footprint and cross core cache line ping pong when incrementing object refcount fields.

(or if going with BRC, correspondingly there shouldn't be a advantages for this custom CPU feature)

Reference counting on Objective-C was plan B, after the failure of implementing a safe tracing GC in a language with C's semantics.

So they went with plan B, having the compiler automate the retain/release messages used by the Cocoa framework.

Everywhere else in Objective-C, the memory is still manually managed, or via memory pools.