Posts for Tag: optimize

Swift 1.2 Update (Xcode 6.3 beta 2) - Performance

Apple have shipped another major update (release notes - registered devs only) only two weeks after shipping the beta 1. There are major updates to Swift Playgrounds, additional syntax support for more flexible `if let`, added a zip function, various other tweaks and fixed a tonne of bugs. This is all on top of the major changes in 1.2 beta 1 that I discussed at Swift London.

Erica Sadun has already blogged about the Playgrounds and `if let` changes and I'm sure that there will be plenty more over the next week. I don't intend to go over that ground but instead discuss the performance changes in Swift 1.2 versions. [Update: I should also have mentioned Jamesson Quave's post that covers the new zip function.]

The performance jumps are very significant in Swift 1.2 and certainly in Beta 2 the steps necessary to optimise your code are significantly changed. This post will cover some information on the improvements and how to get the best out of the Swift compiler. In most cases I have encountered the performance is now very close to C/C++ code and may be faster at times.

Swift 1.2 beta 2 Big Performance News

High performance can be achieved in Xcode 6.3 beta 2 without making code changes to achieve the result that were required to get close previously. Specifically the performance gains of these changes seem to have been largely eliminated:

  1. `final` methods/properties which used to be massive (although I still recommend it where possible for design/safety reasons).
  2. unsafeMutableBuffer instead of array (at least in -Ounchecked builds)
  3. moving code into the same file to allow the compiler to inline (with -whole-module-optimizations build option new in Xcode 6.3 beta 2).

There also seems to have been a slight general performance gain (about 5% above beta 1 from my initial tests).

Is Swift Fast Yet?

Yes. I've always believed that the language had potential to be as fast or faster than C because of strict compile time type checking, immutability and a lack of pointer aliasing concerns. With the Xcode 6.3 betas that promise is being delivered on. I'm sure the work is continuing and there is more to come but it is already fast in most cases. My thanks to the Apple team for making a fast platform but you have just taken away my ability to look impressive by speeding up code significantly with a few simple changes - you bastards.

Overcoming Swift Resistance Explored

This post is a response to David Owens' Swift Resistance Explored post.

First I want to acknowledge that Swift Debug builds are hideously slow. This isn't news to me or anyone who has seen my talk on Swift optimisation. To be clear this is a problem which Apple have said that they are working on but I still don't think it is an absolute block on any real development because there are fairly simple workarounds.

If you want to see the code under discussion it is all in my repository here with a log of my development. The first commit is the Zipfile that David made available in his blog post, the rest is my testing and development of the Swift version.

These are my performance figures (for 100 runs so it isn't directly comparable to David's):


Obj-C

Swift

Optimised

0.077 (1.8)

0.042 (1)

Debug

0.38 (9.1)

13.7939 (327)