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.

Here's a different comparison for what it's worth

http://www.jessesquires.com/apples-to-apples-part-two/

Too Slow for Production _for now_.

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.

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.

I haven't tried Swift yet, so I'm posting this just to know what other experiences people have.

Why not profile and see where the time is actually going? Slow JSON parsing? Slow I/O?