Core Image and Pro-Active Laziness
It may have come to your attention that there’s a new kid on the block when it comes to developing software for the Apple’s Mac OS X and iOS – Swift. With eerie resemblance of Javascript and a strong hint of C++, Swift may appear a little odd at first glance. Curiosity got the best of me, so I decided to put together a few simple, yet informative, test to see how Swift’s Javascript / C++ inspired syntax stacks up to Objective-C in the performance department.
EDIT: The tests were run in iOS 8 (beta 1) and Swift in beta. I revisit this topic when iOS 8 is officially released and Swift exists beta here.
The Measurement
Before we begin, I want to explain how these tests will be measured. Below, we take the startTime via CFAbsoluteTimeGetCurrent(), perform the task, and once again take the end time and subtract the startTime. The result is the time required for execution. Pretty simple.
For each test, we setup a loop and perform some work that is identical in both languages to see how they perform against each other. To see the results more clearly, I’m going to use an iteration count of 1,000,000 in every for-loop. All the test were run on the newest, fastest, 64-Bit iPhone 5S.
Test 1 – String Manipulation
Working with strings is crucial for just about every language out there. In this test we focus on how each language performs a simple concatenation of a mutable string. In Swift, there is no concept of “mutability”. Instead it prefers to use constants for immutable objects via the “let” declaration instead of “var”. Here, in Swift, we the “var” keyword because we want a mutable string.
The equivalent code is Swift would look something like the following:
The results.
Test 2 – Mutable Arrays
One of the most fundamental tasks in any programming language is populating arrays and dictionaries. In this test we compare the speed of adding elements to the end of an array in both Objective-C and Swift. You will notice below that we’re using 100,000 iterations in this test. This is because adding a million elements to an Array in Swift took nearly a minute! The whopping time was 57.6858 seconds!
The equivalent code in Swift looks like this:
The results.
Test 3 – Model Objects
This is likely the most realistic test out of the three. Here we test the efficiency of creating a model object, populating it with some data, and adding it to an array. This a very common scenario especially when parsing JSON over the network, or working with a local database. Let’s have a look at how Swift performs compared to Objective-C. Again, we’re using 100,000 iterations because a million would take too long.
The Models
First, we’re going to have a look at the our model objects. For this test, we are dealing with a simple Person object. It has two string properties and one number property. First, is the Objective-C declaration, followed by the equivalent in Swift. Notice that in both languages, the Person object inherits from NSObject.
The Test
Again, in this test we are using a mutable array to collect and store our newly created Person objects. Let’s have a look at the test in Objective-C first. First we create a container. Then, for every iteration of the loop we create a new Person, assign it firstName, lastName, phone and add the person to the end of the array.
The same is now written in Swift:
The results:
Conclusion
The results were astonishing. To my surprize, Swift’s performance was just atrocious. For simple operations like concatenating strings, populating arrays and creating model objects, Objective-C was order of magnitudes faster! These kind of results may be acceptable for a scripting language but for a language that claims to be on par with Objective-C and C its simply unacceptable. Yes, I agree that at times Swift can be easier to write, more readable and offer the same functionality with less lines of code, but at this point, you have to consider how much performance matters to you and choose your language wisely.
EDIT: To be fair, these tests were performed when Swift was still in beta. Beta 1 to be exact. We shall revisit this comparison down the road when Swift exists its beta stages.
Related posts
Nice article…. Not telling me anything I didn’t already know, and I’ve never coded a single line of Swift.
I can tell you, just on mere text manipulation, parsing, loading, ect… C has almost the same relationship with Obj-C, albeit if you are willing to sacrifice ease of programming / time required for project development.
I’ve written apps 50% of the hard data crunching / parsing / sorting was in C using the standard libs, and you could see the difference, noticeably running the app under obj-c and the C.
I’ve heard them promoting swift for the last two years, how it’s just a smidgen behind C++ in run time… they must have been talking about some serious, non-embedded hardware, where the difference were negligible.
For the object models example the two pieces of code does very different things.
The Objective-C one appends the object in the array, while the swift one creates a new array with the new object and replaces the array reference. There will a lot more array allocation/deallocation than in the objective-c code.
To be fair you should be doing:
container.append(model)
rather than
container += model;
Very nice article. Keep up the good work mate
Did you enable optimization? Swift with no optimization flag
-Ois slow. Comparing Objective-C-O2with Swift-Owill most likely turn the tables.Also, under Swift, let
Personbe a subclass of Swift’sObject, not Objective-C’sNSObject. Your Test 3 tests Objective-C in both cases.Thanks for the suggestion! You’re right about Swift’s performance improvement in response to setting
-Ooptimization flag. I reran the last Model-Object test one more time with no optimization for Objective-C and-Ooptimization for Swift (slightly unfair), and yet Objective-C is STILL roughly 3.5x faster! Granted, this is a massive improvement from non-optimized Swift but it’s still not quite as fast. Also, switching fromNSObjectto Swift’sObjectactually reduced performance by 20%!Thanks for the performance test. Years ago a ran a similar test comparing the scripting language Lua with Objective-C. I compared tables in plain Lua and Luajit with CFArray, CFDictionary, and plain C array. The Luajit was in pair with plain C array with no compiler optimizations for the C program, this was indeed surprising. More interestingly, plain Lua was much faster than NSDictionary and NSArray. This was before ARC. This makes me worried about swift. Have you had a chance to redo the tests as Swift gets closer to 1.0?
Yes! I did a retest with Swift out of beta with the official iOS 8 release. You can find the article here.
I enjoyed reading over this comparison, but I feel that your conclusions were a bit hasty and didn’t give Swift any slack. Swift is still in beta, and we can only assume Apple is still working on improving it’s performance. Additionally, you completely ignored the compiler optimization settings of -O and -Ofast.
I agree with you completely. I’m sure that as Swift evolves and exits the beta stages, the performance will likely improve. My attempt in this article was to simply run Swift through some basic preliminary tests to see how it compares to Objective-C at the moment. I will also be coming back to explore this performance comparison later on when Swift matures a little bit.
nice article.. but.. a typo:
You wrote JAVASCRIPT!
🙂
I apologize about that. The syntax highlighting plugin didn’t have support for Swift at the time, and Javascript syntax was a close resemblance. It has since received support for Swift, and the article has been adjusted accordingly.
Test 1 should use *let* instead of var inside the loop, because contrary to the Objective-C example it creates a mutable String, not an immutable one:
Would be interesting to see if this has an impact.
Klaus
Thanks for pointing that out Klaus, I’ve edited the post to reflect the change. Also, I reran the tests to see if it has made a difference and unfortunately, its made none whatsoever. In fact, I haven’t been able to clock in a faster time than what’s already posted.