ARM64 and You
Adding it all together, it’s a pretty big win. My casual benchmarking indicates that basic object creation and destruction takes about 380ns on a 5S running in 32-bit mode, while it’s only about 200ns when running in 64-bit mode. If any instance of the class has ever had a weak reference and an associated object set, the 32-bit time rises to about 480ns, while the 64-bit time remains around 200ns for any instances that were not themselves the target.
In short, the improvements to Apple’s runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that’s a big deal.
Update (2013-10-16): Bob Wilson:
At the time iOS was first developed, SjLj was the only exception handling mechanism supported by GCC for ARM. I think DWARF unwinding support for ARM may have been added to GCC right around the same time but it didn't arrive quite in time to be adopted for iOS. Changing it after the first release would have been a major ABI break, so we've been stuck with SjLj. Note that the new 64-bit iOS ABI does _not_ use SjLj.
