3 ms·

You're right... I sort of contradicted myself there by calling an implementation using Objective-C objects 'idiomatic', since nobody in their right mind would i

You're right... I sort of contradicted myself there by calling an implementation using Objective-C objects 'idiomatic', since nobody in their right mind would implement that example using NSArrays and boxed values. My point was really that Objective-C isn't always faster than the equivalent Java (a function call, hash lookup and jump is fast in most contexts, but it's still infinitely slower than nothing, which is the overhead of a JIT-inlined method call), but that being a superset of either C or C++ means that it can be faster when it needs to be. Which is ultimately what matters.

mikeash 13y ago
Yep, you can definitely construct Objective-C code that would be way, way, way slower than equivalent Java code. A trivial example would be something like for(int i = 0; i < 1000000000; i++) [obj self];. I imagine any decent Java JIT will be able to detect that this loop does nothing and eliminate it entirely. However, my point is that not only can you write faster Objective-C code, but that most normal Objective-C code will be faster, because most normal Objective-C code isn't that message heavy. So it's not just that it can be faster, but that it usually will be. Typically. Depending on what you're doing.