I can't think of a good reason other than "I don't want to compare C-style sort with Swift because I want to talk about Objective-C". This is an incredibly poor benchmark in my opinion, since if you were dealing with a ton of ints in an Objective-C program you'd probably be dropping down to C or (in the case of ObjC++), C++. Back when Swift was slower and losing, I suppose it was eye opening that despite all this ObjC was still winning.

That's not to say that there isn't any insight here, I just think the much more powerful argument would be "look, in Swift we can get C-like speed without having to use icky primitive arrays". Which is actually a pretty powerful selling point (if its true, which we don't know, since C-style sorts aren't compared here).

That's a little harsh. I for one think that it's a perfectly reasonable thing to do. The benchmark was how does Swift go compared to Objective-C, not C. That is, if you're using those nice data structures that make life easy in Cocoa, what sort of a speed hit can you expect. As an example, say I want to use an NSArray because I need to serialize the contents, or because some other module expects an NSArray, it's a pain in the neck and a source of bugs if I have to translate safely from a C array to an NSArray every timie I want to use it (and if that array is mutable?)

This benchmark shows how things perform when you're using the nice, safe array (because let's not forget that an NSArray is much safer than a C array). In Swift you get performance that absolutely trounces the equivalent functionality in Objective-C. That's a nice thing to know.

I think we agree, but let me explain.

> The benchmark was how does Swift go compared to Objective-C, not C

Objective-C is a strict superset of C, in other words, there's no such thing as "Objective-C, not C". This is not me being pedantic, its an incredibly important feature and selling point of the language. You are making ObjC perform with one arm tied behind its back, exposing all of the pitfalls with none of the benefits.

> In Swift you get performance that absolutely trounces the equivalent functionality in Objective-C. That's a nice thing to know.

Precisely. I think there is a great blog post about how you get certain things in Swift for free that would be time consuming/hard/whatever in Objective-C. But without making the actual comparison, we can't know or understand that tradeoff. If this also showed pure-C or ObjC++ perf, I would walk away thinking "damn, I can get 0.9x the speed of C AND have it be safe? Cool." Instead, here I'm just left thinking "ok, so Swift is faster than something I'd never do in Obj-C. Great." Then immediately I'd start asking "wait, isn't this maybe just because we're using an expensive -[NSNumber compare:] thousands of times? Maybe this can be trivially remedied by changing that call to compare to direct accesses to the internal ints?"

Edit: As an additional comment, I'd point out that you'd make an IntArray subclass to the NSArray class cluster to get both the perf and serialization of NSArray. Again, convoluted and unnecessary work, but ultimately what you'd actually do in ObjC.

Well, It is a comparison between Objective-C and Swift, after all. He is using the proper data structures in each language for this tests. It's true is not the most efficient way to go about it in an Objective-C app, because you can mix it with C and C++, but then you wouldn't be using Objective-C, and the title of the article probably wouldn't be "An analysis of sorts between Objective-C and Swift".

(See above response). Sure for C++, but certainly not C. When you use a double in Objective-C its not "no longer Objective-C and actually C now". C is a part of Objective-C. Not using c-style arrays is an arbitrary limitation, and forcing one to not use the proper data structures. No one recommends using an NSMutableArray for gigabytes of ints, it is well established that it is not the proper data structure for that. That being said, I totally agree that it is better in Swift. My point is simply that the demonstration should be one of the impressive ease of use/performance tradeoff vs. a questionable raw speed comparison where you don't actually see how fast it would go in a shipping Objective-C program that used every available tool at its disposal.

In other words, this blog post could be misinterpreted to give the impression that apps will now necessarily get faster thanks to Swift. But this is certainly not true if the C version is 1) faster and 2) in wide use. Instead the argument should be apps will be more reliable at negligible speed loss, and possibly even faster (again we don't know since that benchmark wasn't done).