Posts for Tag: optimisation

Swift AsyncSequence Performance Experimentation

[UPDATE 16/8/2021: Xcode/iOS beta 5 seems to make a massive jump in performance. I'll blog again when I get round to it but wow. From first glance async appending byte by byte appears to be only 3x slower than sync call to load data and the XOR tests are actually faster now in my initial testing.

Updated conclusion - If you can drop iOS 14 support then there is no performance reason not to use AsyncSequence type operations on files and lots of positive reasons to use it.]

At WWDC 2021 amongst the other async talks there was the Meet AsyncSequence talk which amongst other things demonstrated new APIs for getting async sequences of bytes from files or URLs. I was curious as to how they would perform so I did a few tests. Note that the FileHandle and URL bytes properties do not seem to be working in Xcode 13 beta 1 but the version on URLSession does seem to work and can be used for files - see the updates on my last post 

This is a very first pass with some rough numbers to get a feel for rough ballpark feeling. This is iOS 15 beta 1 (on iPhone XS) and Xcode 13 beta 1. Testing was done with -O (speed) optimisation setting. The tests themselves will be at the end of this post. I configured the tests to run just the once because first run performance was consistently slower and I thought therefore more representative of file reading where the file is not already loaded.

As a baseline I included a pure synchronous read into a Data object. The AsyncSequence approach should not get close to the performance of this as it has to do a great deal more context switching at least function calls whereas that is straight-line on a single thread code.

Results

Swift Performance - iOSDevUK

I presented today at iOSDevUK in Aberystwyth with some more material on Swift Performance and how to profile Swift. Also on wrapping classes in value types. Unfortunately much of the presentation was a demo and there is no video but I'm posting the materials here and will try to make a follow up post covering some more of the details in the next week or two (no promises).

Slides (note that slides a terrible communication mechanism and caveats and subtleties in the talk may be lost):

How Swift is Swift?

Slides, video and links related to my Swift Summit talk on Swift performance. Video should be available later is now available and it might be worth watching Airspeed's talk that preceded mine before watching it when it is available I'm also expecting a blog post from him shortly on his static vs. compile time talk which is also highly relevant to optimisation.

The key point in Swift is that as the compiler gets better there is no need to choose between nice code and fast code. With a little thought and knowledge it is usually possible to get close to the speed of lowish level C code with nice abstractions. Some may say that C++ is there already but I enjoy writing Swift code much more and C++ is hampered by it's C legacy and choices made many years ago (for good reasons) from becoming a truly nice language in my view (non-Nullable by default would be hard to retrofit for example).

There were also many other excellent talks at Swift Summit, and all were at least good. I'm looking forward to watching several again.

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)