Item — HN Reader

In theory Swift's arrays are little more that a c array + length, and this is how we have been encouraged to use them.

The issue here is nothing about "managed code", but about how the Swift compiler behaves without any optimization passes. Currently (and it should be noted that this is a recognized issue), the unoptimized builds are orders of magnitude slower than ObjC because Swift will auto refcount code that in ObjC is either not ref counted at all, or uses manual RC. After optimization, Swift can eliminate many uses and put things on the stack etc, but we are at the mercy of the optimizer for that.

Compare this to the (compararively) predictable behaviour you have in C.

Yes we can in theory use UnsafeMutablePointer everywhere, but in that case it's much more efficient to write the function in C instead.

I would wager that the problem is that Swift arrays aren't just a pointer plus a length, but rather a pointer plus a length plus copy-on-write semantics. You probably need some smart optimizations to eliminate the copies, and I'd put good odds on the performance problems here coming from lots of unnecessary array copies.

I'd have to check in detail, but just looking at the profiler, about half of the time is in the actual setter code and half in bounds checking. One would think that bounds checking is a faster operation than the set if copy-on-write is the culprit? But maybe it does some other magic as well. Something you notice though is that release/retains are everywhere.