Swift Performance: Too Slow for Production(blog.sudeium.com) |
Swift Performance: Too Slow for Production(blog.sudeium.com) |
The initial Swift version the author created uses a third party library for wrapping the JSON decoding and that library appears to create a metric shit ton (technical term) of short lived objects whilst performing its magic. I cobbled together a less memory insane version (likely similar to the one described as Obj-C in Swift - although I disagree with that description) which is an order of magnitude faster. Finally there is an Objective-C version which is an order of magnitude faster again. All tests were running on an iPhone 5s in release mode.
Decoding JSON is an annoying task for most languages. That Swift decodes half a megabyte of JSON in a tenth of a second is a reasonable trade off, for me, when comparing it to the verbosity and occasional fiddlyness of working with Obj-C. It was quite nice to see how simple it was to mix Swift and Obj-C as I was creating this, so that suggests little downside to using Swift for the mundane tasks and coding specific bits in Obj-C when that's necessary for speed reasons - although Obj-C is not uniformly faster than Swift as noted in other articles.
I for one would not be changing my approach based on this post. I might start doing some disassembly if I was writing performance sensitive production code in Swift, but that would be about it.
Also, "fast as C" is a slippery little thing; anything can be fast as C on some benchmark with an optimization for that benchmark, being reliably as fast as C and being able to engineer in the confidence that something is as "fast as C" all the time is quite another. Witness the number of people who will vigorously claim that Javascript implementations are "as fast as C", despite in reality not being anywhere near that except in the aforementioned carefully-engineered benchmarks. Especially beware of "adding integers in an array". That's easy to optimize and nowadays says little since everyone optimizes for that case, knowing it's going to be benchmarked.
In other news, the latest web framework is "easy to use" and "powerful" and probably "MVC". This is just throat clearing, not a description anymore, because nearly everything is "easy to use" and "powerful" and "MVC". Also, half the libraries posted to /r/$LANGUAGE are "A simple, powerful library for X", which probably translates to "A library I spent about 4 hours on" rather than any sort of increased probability of it being either simple or powerful.
I believe Smalltalk is as about as much of an influence as C.
Lots of Objective-C programmers actively dislike Swift because it's so static.
So... Main conclusion is that Swift is not production ready yet.
Swift hasn't even been out for a year. Look at the progress it made since summer, it sped up a lot in certain parts.
Just file a radar on what's slow and they'll fix it.
Apple intentionally is shipping Swift as is to get devs ready and start planning for the next five years.
A lot of experienced Apple developers do not expect Apple to support two languages for a long time. With all the noise Apple made about Swift, it will be getting more TLC than Obj-C and eventually, Obj-C will not be supported anymore.
We're not talking about a few years, we're talking maybe Carbon>Cocoa style, 5 years before Apple starts warning devs that Obj-C would be phased out in several years.
I didn't spend a huge amount of time profiling this though, since it's very early days in my project and it'd take me less time to just rewrite what I'd done so far in a language that I know works.