Overlooked C++. My point stands for managed runtimes. ObjC/Swift don't have to deal with the following laundry list of things the managed runtimes need to implement:
- Explicit instrumentation for null pointer checks (slow)
- Explicit instrumentation for stack overflow checks (slow)
- Explicit instrumentation for GC safe points (slow)
- Exceptions and unwinding implemented on top of cxx_throw instead of signals and setjmp/lonjmp (slow and error prone)
- Defensively generated trampolines for reflection for any thinkable parameter type permutation
There are quite a few more details that make managed runtimes under bitcode suboptimal.
Taking away things like read/write register access, signals and system APIs like setjmp/longjmp puts managed runtimes at a huge disadvatage.
Neither Swift nor ObjC (and to a large degree C++) need to solve any of these problems.
I doubt very much any of those issues will show up relevant values in a profile run, which is what actually matters, not the theoretical value of a few ms more that the user hardly notices.
There is also room for the AOT bitcode optimizations to hoist many of those checks, specially since the AOT compilation takes place at the store side with lots of resources available.
Android and Windows Phone have already proven that those issues aren't an actual issue from the user point of view, specially on the Android side if you take into account the market share.
I've worked on both RoboVM and Mono, I can tell you first hand that these are issues that are real and have high impact on performance.
Android and Windows Phone don't lock their respective managed runtimes down like Apple does lock down the likes of Mono/Xamarin. On Android you have full access to almost everything, and on Windows Phone MS has a vested interest in exposing all required features to their managed runtime. No such luck on Apple hardware.
