I’m not deeply familiar with swift, objective-C or the next-step APIs, but it seems like they’re describing the difference between a (virtual?) function call (ie: swift to swift) vs a “message passing operation” in objective C. If that assessment is correct, then it’s really an exercise in small costs adding up quickly. If you call through the function pointer you have way lower latency, and if you call through the same operation hundreds of times to render a single screen (the calendar) inside of the render loop where latency matters- that’s measurably better. Especially on a device that tries to throttle CPU frequency to save battery power.
This is somewhat analogous to the same arguments that can be had about JIT compiled languages having the the opportunity to exceed performance of AoT compiled ones because of inlining opportunities- except in this case I don’t know if the call has any chance of being actually inlined so much as at least bypassing the message passing machinery overhead.
This is somewhat analogous to the same arguments that can be had about JIT compiled languages having the the opportunity to exceed performance of AoT compiled ones because of inlining opportunities- except in this case I don’t know if the call has any chance of being actually inlined so much as at least bypassing the message passing machinery overhead.