Exploring borrow and mutate in Swift 6.4: Hands-on Project & Performance Insights

Hi everyone,

After watching the WWDC26 sessions and diving into the recent ownership proposals, I wanted to test these concepts in practice using the Swift 6.4 Beta.

I built a hands-on project to experiment with borrow and mutating behaviors, specifically looking at how the latest updates eliminate hidden performance costs.

I’ve documented my findings, code examples, and the project details in this article:

Swift 6.4 Just Eliminated a Hidden Performance Cost

I would love to hear your thoughts and feedback on this approach!

2 Likes

It’s nice to see actual performance figures!

I do think you’re misrepresenting how copies work, though:

Copying takes times and uses memory. If your array has only 10 items, it is not problem. But if you work with audio files or something like that, your array might have 44.000 items per second. Copying big data every time makes your app slower.

Copy-on-write makes this less of an issue. The thousands of samples aren’t copied when Swift copies the Array; it just increments the internal ref-count. The full copy only happens when mutating the array if it has multiple references.

That's why your read test barely sped up, while the write test became much faster. (Which you did explain later on.)

I’d love to see some bigger examples of borrow/mutate accessors with benchmarks; the few I’ve seen, like yours, are kind of contrived — no one would really create a mutable computed property that just directly exposes a stored property, vs just making the stored property public.

2 Likes

Thanks for the feedback. You are completely right about CoW. I will refine that part of the article.

And you are also right about the example. I am testing this in Beta right now, so I used a simple wrapper to see the mechanism. When Swift 6.4 is officially released, I will update the article with a real-world example. Thank you :slight_smile:

1 Like