Performance isn't about what you believe should be true, but about what actually is true. Kinda like science. (versus religion)
> ObjC’s only innate advantage is compile time
Objective-C has a bunch of advantages. Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile.
And there are languages with very comparable feature sets to Swift that are way faster to compile.
> At runtime Swift can utilize static dispatch
"can"
> where objective C is mostly dynamic.
Not true. The C part of Objective-C (it is most of the actual language) is very static.
Also, Swift has some pretty amazing dynamic performance pitfalls. For example protocols. You see, protocols in Swift can be adopted by both structs and classes. Meaning that when you call a function via a protocol, the compiler doesn't even know the size of the arguments or how to access them or copy them into the function's scope. So even that has to be handled by a small vtable, and you haven't actually done anything with that argument yet!
As this is one of the many places where Swift can lose a cool few orders of magnitude of performance, you obviously need the optimiser to specialise the function for specific callers. Which it can do, sometimes, at some cost, as long as it can actually see the caller and callee at the same time, in the same compilation unit.
IIRC, Uber had an OOPSLA paper describing the extra compiler pass they had to write to get their app's performance to at least somewhat acceptable levels, because the existing optimiser wasn't good enough.
And when you want to do separate compilation, you're sort of hosed, because you don't have access to the caller when you compile the callee.
Agree with most of your comment, but Uber’s thing was probably just as likely to be a team unable to say “no” to new code rather than one that “needed” people to anneal compiler passes
Performance isn't about what you believe should be true, but about what actually is true. Kinda like science. (versus religion)
> ObjC’s only innate advantage is compile time
Objective-C has a bunch of advantages. Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile.
And there are languages with very comparable feature sets to Swift that are way faster to compile.
> At runtime Swift can utilize static dispatch
"can"
> where objective C is mostly dynamic.
Not true. The C part of Objective-C (it is most of the actual language) is very static.
Also, Swift has some pretty amazing dynamic performance pitfalls. For example protocols. You see, protocols in Swift can be adopted by both structs and classes. Meaning that when you call a function via a protocol, the compiler doesn't even know the size of the arguments or how to access them or copy them into the function's scope. So even that has to be handled by a small vtable, and you haven't actually done anything with that argument yet!
As this is one of the many places where Swift can lose a cool few orders of magnitude of performance, you obviously need the optimiser to specialise the function for specific callers. Which it can do, sometimes, at some cost, as long as it can actually see the caller and callee at the same time, in the same compilation unit.
IIRC, Uber had an OOPSLA paper describing the extra compiler pass they had to write to get their app's performance to at least somewhat acceptable levels, because the existing optimiser wasn't good enough.
And when you want to do separate compilation, you're sort of hosed, because you don't have access to the caller when you compile the callee.
> Good swift code should generally be faster.
That turns out not to be the case.