> 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.
> 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.