I hacked together a quick reproduction of this since the author didn't provide any working code. I don't really know Swift and my Objective-C skills are pretty rusty at the moment, but it compiles and show similar performance characteristics: https://github.com/mnem/swift-json-speedtests
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 find posts like this nearly entirely lacking in interest. There was so much attitude and not near enough actual analysis. A much stronger post would have actually disassembled the resulting code in each of the different configurations, and looked to see why the various permutations had the performance that they did. We would then have a much stronger understanding of where Swift's performance is at, instead of looking at a series of not exactly equivalent benchmarks that leave us wondering if we're not just seeing an artifact of the differences in the benchmark code as opposed to differences in real-world performance.
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.
Cough When it comes to describing languages, there's a set of words you should just consider vacuous throat-clearing until proved otherwise. This includes "fast", "powerful", "robust", "easy to [pretty much anything]", "featureful", and a few others. Why is this? It isn't because it's impossible for any of these things to be true; all of them have been true of some language somewhere, even on initial release. It's because every language always claims 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.
Even as Python programmer I find the boast "2.6x faster than Objective-C and 8.4x faster than Python 2.7" pretty bizarre. So Objective-C is a statically typed, compiled, C superset and still only 3.5x faster than Python? That is not really something to be proud of.
Not an Objective-C programmer, but while includes static typing, it's also very dynamic. It uses a message-sending paradigm and you can construct messages at run-time from strings.
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.
The point is that author of original post was unable to get it compile with optimization turned on because of internal compiler errors. So yep, Swift can be faster but so far you must be lucky enough to get it compiled.
So... Main conclusion is that Swift is not production ready yet.
I'm currently deciding whether to start a project in Swift or Objective-C, I know very little about either, for learning purposes Objective C has the edge but I don't want to invest time learning something that's on its way out.
Why not? This is Apple we're talking about, they're famous for getting rid of older stuff.
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.
Blog author here. I actually did: the vast majority of time is spent in the Swift Runtime. The JSON parsing is via NSJSONSerialization, which is an Apple library written in Objective-C, and it's fast. I'm not measuring IO, I'm only measuring the time spent turning the NSDictionary objects that come back from NSJSONSerialization into my model objects.
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.
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.