Swift Language Concurrency Concurrent Loops
Example
GCD provides mechanism for performing a loop, whereby the loops happen concurrently with respect to each other. This is very useful when performing a series of computationally expensive calculations.
Consider this loop:
for index in 0 ..< iterations {
// Do something computationally expensive here
}
You can perform those calculations concurrently using concurrentPerform (in Swift 3) or dispatch_apply (in Swift 2):
3.0
DispatchQueue.concurrentPerform(iterations: iterations) { index in
// Do something computationally expensive here
}
3.0
dispatch_apply(iterations, queue) { index in
// Do something computationally expensive here
}
The loop closure will be invoked for each index from 0 to, but not including, iterations. These iterations will be run concurrently with respect to each other, and thus the order that they run is not guaranteed. The actual number of iterations that happen concurrently at any given time is generally dictated by the capabilities of the device in question (e.g. how many cores does the device have).
A couple of special considerations:
-
The
concurrentPerform/dispatch_applymay run the loops concurrently with respect to each other, but this all happens synchronously with respect to the thread from which you call it. So, do not call this from the main thread, as this will block that thread until the loop is done. -
Because these loops happen concurrently with respect to each other, you are responsible for ensuring the thread-safety of the results. For example, if updating some dictionary with the results of these computationally expensive calculations, make sure to synchronize those updates yourself.
-
Note, there is some overhead associated in running concurrent loops. Thus, if the calculations being performed inside the loop are not sufficiently computationally intensive, you may find that any performance gained by using concurrent loops may be diminished, if not be completely offset, by the overhead associated with the synchronizing all of these concurrent threads.
So, you are responsible determining the correct amount of work to be performed in each iteration of the loop. If the calculations are too simple, you may employ "striding" to include more work per loop. For example, rather than doing a concurrent loop with 1 million trivial calculations, you may do 100 iterations in your loop, doing 10,000 calculations per loop. That way there is enough work being performed on each thread, so the overhead associated with managing these concurrent loops becomes less significant.
