A roadmap for improving Swift performance predictability: ARC improvements and ownership control

[Joe_Groff]

@bnyu

do we have plan to reduce the atomic accesses of ARC when data will not cross threads or tasks?

We may investigate this more when the concurrency model has been better fleshed out. Some of the features planned to enforce data race safety may allow us to know when certain references are thread-isolated and can use nonatomic refcounting.

@Alejandro_Martinez

If I understand correctly this means we won't have to "strongify" weak bindings to keep them alive during the same lexical scope? It always felt too extreme to have to do that.

What is not really clear is if a binding is no longer used after the middle point of a scope, will it still be "released" at the end of it or it will be immediately after its final use? I have a disconnect between what assumptions can be made as a general rule vs. in specific code.

Working with the weak reference itself shouldn't change much under this proposal. If you're going to perform multiple operations on the same object, you'll still want to "strongify" the reference to ensure you have a stable reference for the duration of those operations. But if let and guard let in Swift already do that for you. Lexical lifetimes intend to make the side that holds the one strong reference to the object less hazardous, by making it less likely you need to use withExtendedLifetime to stop the optimizer from shortening the lifetime of the strong reference.

@Alejandro_Martinez

And I wonder what Rust does here .

Rust has "non-lexical lifetimes" too, though it's stricter than Swift's traditional rule, since the end of a binding's lifetime is pinned to its last use in source, whereas Swift didn't consider no-op loads like _ = x to be formal uses of x, and so inlining and other optimizations could allow lifetimes to shorten even further than the last source-level use of the variable. Rust's non-lexical lifetime rule could however still pose a hazard for weak references in the example from the original post, since the last source-level use of the strong reference to the delegate object still happens before the access into the weak reference.

@Alejandro_Martinez

I'm still not sure I understand what provokes a change on the behaviour.

Are you saying that right now there is no copy when sorting because the values lifetime ends before the sort call and so we get the good performance we want? and that with the changes that won't be true anymore and thus we will have to explicitly move ownership to get avoid the copy?

If so, even tho I understand the overall goals, this feels like a regression on the smartness of the compiler/language :(

In this particular example, there would be no change from today, since the initializer contains no deinitialization barriers. Both today and with lexical lifetimes, you will likely see an extra copy on write in debug builds, because people generally expect local variables to be readable anywhere in scope in the debugger, and maybe that copy will be elided in optimized builds, but there's no strong guarantee either way. move provides a way to assert an important performance property, but it still isn't strictly necessary to get the benefit of optimization.

@Alejandro_Martinez

One thing I'm wondering tho is if there is a way the language can expose a more consistent view on coroutines. If I'm not mistaken, won't we have now multiple "coroutine like" systems? async/await and read/modify. It feels like those features are in reality just one. (I remember the starting days of async discussions and how it was decided to give them more specific names, now it feels like a more general was a better idea). I'm thinking other places of the language/stdlib would benefit from it.

I would say that async is different from other coroutines, because the coroutine transform for async functions is really an implementation detail; they otherwise behave like regular functions at the surface level. The ownership manifesto does discuss supporting generator coroutines in the future, which would allow for more efficient for loops that borrow their underlying sequence's storage, similar to how accessor coroutines allow for more efficient property access than get/set functions.

@Michael_Ilseman

Are assignments considered explicit or implicit copies? Similarly for subscript and var setters that appear in source code as assignments.

An assignment is effectively destroying the old value in the LHS, and consuming the new value from the RHS. It would make sense to me if we still required an explicit copy or move if the RHS is a non-implicitly-copyable expression, and the assignment would necessitate a copy of the underlying value, so if you had:

@noImplicitCopy var x: ExpensiveType = expensiveValue()
var y: ExpensiveType, z: ExpensiveType
...
...
y = copy(x)
z = x

the copy on the assignment into y would be required at minimum, since expensiveValue() has to be copied to be able to assign into both y and z.

@Michael_Ilseman

Yes please! Have you thought about whether this is const poisonous and how to avoid it if so? For much of the code that I write, I almost want this to be the default for non-trivial values, but only if every function that I need call has been similarly carefully annotated and considered. But this is great for leaf functions!

I think that, in order for it to be effective, @nonescaping will have to be viral to some degree like const, and it'll need to be retrofitted to a good chunk of the standard library in order for @nonescaping operations to be expressive. As part of the eventual proposal for @nonescaping, we shouuld discuss how we can manage that annotation burden.