Async.legacy - Swift wrapper for Grand Central Dispatch (iOS7 and OS X 10.9 compatible)

While GCD is a fairly simple API enabling blocks to be dispatched asynchronously on different threads or on particular queues that doesn't mean that the API can't be cleaned up a little to make it really nice to use with Swift.

Tobias Due Monk released the Async library that does just that. I saw the announcement probably on iOSDevWeekly and I liked what I saw except there was one fatal issue for me in that the library required iOS 8 or OS X 10.10 and I haven't updated my devices yet let alone moved my target up to that version yet. I actually just left it and ignored it but having done the optimisation of the GrayScott code presented at the last Swift London meetup I felt comfortable enough with GCD that I could implement most of the fuctionality to work with iOS 7 (and OS X 10.9 Mavericks but just take that as read every time I mention iOS 7 in this article). The result was Async.Legacy

How to Use Async (or Async.legacy)

All you need to do is to drop in the Async.swift (or AsyncLegacy.swift if you are using iOS7) into your project and then you can call the methods. There is full API documentation in the Readme files and that are easily viewable on the Github pages but essentially what Async allows you to do is chain a series of Asyncronous calls rather than to nest them. The result looks like:

Instead of having to nest the calls like this:

From 41 frames per second to 1560 - Full app 38x speedup

Having spent a couple of evenings back porting Async to iOS 7 and OS X Mavericks (10.9) and releasing it as Async.legacy I've gone back to trying to squeeze some more performance out of the GrayScott Cellular Automata app that Simon Gladman presented at the last London Swift Meetup.

For me this was an interesting case to see how fast something that is almost entirely CPU and memory bound can be made and it gave me a chance to play. Not many things need optimising if well strutured but this was a case where it could clearly be relevant.

Simon's original code calculates about 10fps in debug mode and displays many of them. Built with optimisations it increases to about 41fps calculated but it very rarely updates the screen due to the timing mechanism he used rather than calling back to the main thread. All this was done on a 70 pixel square calculation.

Running the latest code on a 70 pixel square calculation it calculates between 1550 and 1600 frames most seconds for a speedup of about 40 times and it is displaying far more frames to the screen too (well assigning the images to the image property of the imageView, the screen framerate is far lower).

This post focusses on making the main solving work multi-threaded for performance and in the optimisation of the inner loop. At this point we are moving beyond the point where we are optimising by improving the style, purity and immutability of the code. Some of the changes (inlining simple functions) go directly against good style and should only be done in inner loops. The parallelisation of the main solver is also something which makes the code less clean and tidy as is the incorporation of the pixelData generation into the main loop.