Swift 1.0 Performance and Compilation Times
About a month ago, Jesse Squires published a post titled Apples to Apples, documenting benchmark results that he claims show Swift now with a roughly 10x performance advantage over Objective-C. Although completely bogus, the post was retweeted by Chris Lattner (who should know better, and was supposedly mostly interested in highlighting the improvements in the Swift optimizer, rather than the bogus comparison) and has now been referenced a number of times as background knowledge as to the state of Swift. More importantly, though the actual mistake Jesse makes is pretty basic and not that interesting, it does point to some deeper misunderstandings about performance and language that I at least do find interesting.
[…]
A second takeaway is that the question “which language is faster” doesn’t really make sense, a more relevant and interesting question is “does this language make it hard/possible/easy to write fast code”. Objective-C lets you write really fast code, if you want to, because it has the low-level chops and an understandable performance model. Swift so far can achieve reasonable performance at times, ludicrously bad at other times (especially with the optimizer turned off, which hardly fazes Objective-C), with as far as I can tell fairly little predictability or control. Having 10% faster (or slower) performance for code I don’t particularly care about is not worth nearly as much as the knowledge that I can get the 1-5% of code that I do care about in shape no matter what. Swift is definitely not there yet, and given the direction it is taking I am not sure whether it will allow that kind of control, at least in comprehensible ways.
[…]
A third point is something more general about language. The whole argument that NSNumber and NSArray are “built in” somehow and int is not displays a lack of understanding of Objective-C that to me seems staggering. Even more so, the whole idea that you must only use what comes provided with Cocoa and are not allowed to build your own flies in the face of modern language design, throwing us back to the times of BASIC (Cathy Doser, in the comments).
Recently I discovered that our current project is seeing O(n²) compile times. While a small project compiles real fast, compile times for projects with 20.000+ lines of code will easily take a few minutes to compile. This is Swift supposedly at 1.0 with no optimizations turned on.
In other news, using Dictionary instead of NSDictionary when interfacing with ObjC code was able to incur a performance penalty of over 14000%. Yes, that’s Swift being 140 times slower than using NSDictionary.
Furthermore, putting your source code in the same or different files can give you a performance penalty of over 3000% in itself. Again, yes that is Swift being 30 times slower if you call something in a different file.
[…]
I’d like to see Swift succeed. It is certainly less bulky than Objective-C. However, when Swift becomes unworkable for projects exceeding 15.000 LOC, then no amount of liking the language is going to help. Nor will you be able to replace it with ObjC/C if you have a performance sensitive application.
Marcel Weiher on the compilation time:
1000x slower? Wow, that’s worse than I would have expected (and I expected bad). Unlikely to change significantly (see C++,Scala etc)
Expensive default semantics, 100% reliance on optimizer to get remotely reasonable perf., unpredictable performance model.
I still like the potential of Swift, but it sounds like it’s currently very easy to paint yourself into a corner. It is troubling that basic features like dictionaries are so slow.
Update (2014-09-14): Christoffer Lernö:
Since Scala is a bit infamous for slow compilation times – partly attributed to type inference – my fear has been that Swift would remain fairly slow at compilation. However, I’ve been assured that Swift’s model is much closer to that of F# and C#. The current O(n²) compiler times are due to bugs and not due to any inherent complexity in the language itself.
4 Comments RSS · Twitter
Dictionaries are not particularly slow. The thread you link is about Objective-C code, doing text layout calculations, constantly hitting the bridge between Swift and Objective-C dictionaries. It would trivially be fixed by forcing an upfront conversion in such cases (e.g. an overload that takes a Swift dictionary and calls the function with a converted NSDictionary).
@dictionaries I understand the distinction you are making, but I think if passing a language’s native dictionary to a native OS API is slow, that means that dictionaries are slow in practice. This kind of thing should just work. I also note that Using Swift with Cocoa and Objective-C does not make any mention of slowness due to bridging. The performance model is undocumented, so one would expect that this is not something you are supposed to worry about.
Apple should make clearer that bridging imposes penalties. I always assumed it would. While I've thus far just written some trivial stuff - certainly nothing I'd worry about speed in - I tend to use Swift with Cocoa native classes like NSDict and NSString just because it seemed safer. (Plus during the betas I kept finding weird gotchas)
I'm less worried about compile times than I am performance. But even though Apple says this is 1.0 even a 1.0 product should make people think twice before using it in production stuff.
[…] Swift 1.0 Performance and Compilation Times, Slow Swift Array Type Inference, Swift Type-checking Performance Case […]
