Can anyone explain the reasoning behind this difference? The article only mentions "In Objective-C, NSArray and NSNumber are used intentionally as the counterparts to Swift's Array and Int."
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).
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.
> 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.
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).