story
Yes, Apple's claims are wrong, sometimes comically so, particularly when it comes to performance. Remember when they claimed that GC was many times faster than retain/release? Also wrong. Or their claim that you should use property lists only for smaller data sets, and keyed archiving for larger data sets? Completely wrong, as keyed archiving uses property lists in its implementation, and always generates larger plists than if directly expressed. So a keyed archive is always worse, performance-wise, than an equivalent plist. And so on and so forth.
Anyway, I have a whole chapter in my book on this, and the numbers tell the story. I obviously can't reproduce the whole thing here.
> but ObjC is somehow faster despite having to do more work.
Another misconception. Swift does a lot more work. It then tries to remove that work through optimization efforts, which may or may not succeed.
A tiny, somewhat extreme example: Swift allocates local variables on the heap. Not as a frame, but individually. At least initially. Now of course this would make code many orders of magnitude slower, so the optimizer (this is a mandatory pass, run even at -O0) has to remove this if it can. However, this is just an optimization, so as far as I can tell there is no diagnostics if it fails.
See https://www.youtube.com/watch?v=Ntj8ab-5cvE
Slides: http://llvm.org/devmtg/2015-10/slides/GroffLattner-SILHighLe...
Then there is mandatory/invisible ARC, which can and will get you in an inner loop, without visibility, and with not much recourse. Even Chris has admitted that this is a problem they need to fix. And of course generics are implemented via witness tables, so indirect dispatch at roughly similar costs to objc_msgSend(). The compiler may be able to eliminate this. Or not.
And so on and so forth. I just saw something about blocks always causing heap allocations (and this is corroborated by an attempt someone made to port some HTTP parsing code from C to Swift. Even with max. optimizations and inline craziness, it was ~3x slower).
Or JSON "parsing". The Swift solutions that tend to sit on top of NSJSONSerialization have tended to be an order of magnitude slower than NSJSONSerialization by itself. Which is odd when you consider that NSJSONSerialization uses all the slowest aspects of Objective-C/Foundation: keyed access, heap allocated objects for things that would otherwise be primitives, dictionaries instead of objects (typically 10x slower) etc. Yet Swift on top is 10x slower. The BigNerdRanch's "Freddy" JSON parser tries to rectify those problems by being 100% Swift, without NSJSONSerialization underneath. The result is that it's "only" 4-5x slower than NSJSONSerialization. And again, NSJSONSerialization isn't particularly efficient.
I haven't tested the Swift 4 serialization stuff yet, but both from reports I've heard and cursory looks at the implementation, it doesn't look like a speed demon.
> Every benchmark I’ve seen shows Swift faster for these reasons.
What benchmarks are you looking at?? While it wouldn't be true that I've never seen a Swift advantage, it's pretty close to never.
Now there are a lot of unsubstantiated claims that Swift is fast, because "reasons", but benchmarks?
