How to code a slow background task made of of several slow steps using async / await - swift

Question

I have a background task that has several slow steps to be processed in sequence. I am trying to understand any difference between the following two approaches in Swift.
First approach:
import SwiftUI
struct ContentView: View {
var body: some View {
Button("Start Slow Task") {
Task.detached(priority: .background) {
await slowBackgroundTask()
}
}
}
}
func slowBackgroundTask() async {
slowStep1()
slowStep2()
slowStep3()
}
func slowStep1() {
// takes a long time
}
func slowStep2() {
// takes a long time
}
func slowStep3() {
// takes a long time
}
Approach 2 is the same ContentView, but with the functions changed as follows.
func slowBackgroundTask() async {
await slowStep1()
await slowStep2()
await slowStep3()
}
func slowStep1() async {
// takes a long time
}
func slowStep2() async {
// takes a long time
}
func slowStep3() async {
// takes a long time
}
Is there any difference between these two patterns? I would be most grateful to understand this better.
Both versions build and run. I am trying to understand the difference.

Answer 1

Regarding the difference between these two patterns, they both will run the three slow steps sequentially. There are some very modest differences between the two, but likely nothing observable. I’d lean towards the first snippet, as there are fewer switches between tasks, but it almost certainly doesn’t matter too much.
FWIW, one would generally only mark a function as async if it is actually is asynchronous, i.e., if it has an await suspension point somewhere inside it. As The Swift Programming Language says,
An asynchronous function or asynchronous method is a special kind of function or method that can be suspended while it’s partway through execution.
But merely adding async qualifiers to synchronous functions has no material impact on their underlying synchronous behavior.
Now, if you are looking for a real performance improvement, the question is whether you might benefit from parallel execution (which neither of the snippets in the question can achieve). It depends upon a number of considerations:
Are the subtasks actually independent of each other? Or is subtask 1 dependent upon the results of subtask 2? Etc.
Are these subtasks trying to interact some some shared resource? Or is there going to be resource contention as you synchronize interaction with that shared resource?
Is there actually enough work being done in each subtask to justify the (admittedly very modest) overhead of parallel execution? If the subtasks are not sufficiently computationally intensive, introducing parallelism can actually make it slower.
But, if answering the above questions, you conclude that you do want to attempt parallelism, that begs the question as to how you might do that. You could use async let. Or you could use a “task group”. Or you could just make three independent detached tasks. There are a number of ways of tackling it. We would probably want to know more about these three subtasks to advise you further.
As a final, preemptive, observation as you consider parallel execution, please note that the iOS simulators suffer from artificially constrained “cooperative thread pools”. E.g., see Maximum number of threads with async-await task groups. In short, when testing parallel execution in Swift concurrency, it is best to test on a physical device, not a simulator.