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.
Worries, worries, worries
Swift has now been in beta since June, and although it was ludicrous to make any predictions from the state for Beta 1, we’re now at Xcode 6 GM and Xcode 6.1 beta 1. – And things are not looking good.
Swift has to overcome several challenges:
- Seamless interop with ObjC while using completely different array/dictionary primitives and ARC release/retain behaviour.
- Cross-file optimization while avoiding the C++ trap of getting long compile times
- Real-time type inference for complicated function/return type/generics combinations
In practice Swift is running into problems with all of the above.
If Swift instead have been built on top of Objective-C, then none of these would really have been a problem. The dynamically typed Objective-C model is almost trivial to compile well in isolation, and type inference would be straightforward since the optional typing would not need to 100% resolve everything completely.
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.
Hopefully one day Swift can be used for more than simple apps.
Unfortunately that day seems ever more distant – and that is worrying.
EDIT: Just to be 100% clear – this is not about the runtime characteristics of the language in itself. Swift has the potential to be just as fast as C. This is about worrying whether the language has a run- and compile time model that is difficult to keep predictable and bug free.
Are you running this code through the optimizer? Believe it or not, that makes a difference. See: http://www.jessesquires.com/apples-to-apples-part-two/
LikeLike
The compile times will obviously not be helped by an optimization pass. As for the performance bugs, my understanding is that they occur with optimization on (or I would consider them fairly irrelevant).
LikeLike
The Apples 2 Apples post does not compare apples to apples. See http://blog.metaobject.com/2014/09/no-virginia-swift-is-not-10x-faster.html
LikeLike
Please file bugs and attach test cases.
LikeLike
Already done.
LikeLike