3 ms·

> If these numbers are true, it might well be true. Objective-C might not suffer from such a significant slowdown. Kinda. I imagine that if these benchmarks we

> If these numbers are true, it might well be true. Objective-C might not suffer from such a significant slowdown. Kinda. I imagine that if these benchmarks were run on idiomatic Objective-C, they'd be an order of magnitude slower than Java. All method calls are un-inlineable and often require a hash table lookup to resolve. However, the nice thing about Objective-C is that it's ridiculously easy to write performance-critical stuff in C or C++, then expose it with a nice OO interface. Which means that you (or, more likely, the people who wrote the library you're using) are more likely to bother. That and the lack of GC making latency easier to reason about. So while it is probably easier to write performant UIs in Objective-C than Java, it isn't because of the reasons mentioned here.

gmac 13y ago
Yes — in fact, it's arguably more natural in most cases to write your performance-critical stuff (e.g. math in loops) in plain C. There's rarely any reason to start boxing values up in NSNumbers and then unboxing them again. In addition, Apple's Accelerate framework makes it easy and natural to take advantage of SIMD for further speedups — you can get powerful vector operations with single function calls. This seems to have no Android equivalent.
- pjmlp 13y ago
  > This seems to have no Android equivalent. Renderscript?
  - gmac 13y ago
    Thanks — previous Googling hadn't turned this up for some reason.
Someone 13y ago
"If these benchmarks were run on idiomatic Objective-C" s/idiomatic/pure/ I haven't programmed it much, but to me, idiomatic objective-C is when you use it as a sort-of scripting layer on top of your C code. No sane programmer would write ten layers of Objective-C message passing code; two or three is fine, on the bottom of your call stack (and hence, rarely executed)
mikeash 13y ago
Objective-C message sends always require a hash table lookup to resolve. That is the fast path. (Edit: almost always. I forgot about the vtable path for a few selectors. It doesn't affect most code and I don't think it's even used outside of x86-64, but it is a non-hash-table path.) However, implying that "require a hash table lookup" is slow isn't really right. The message send implementation is extremely optimized and takes about a dozen CPU cycles to execute last I measured. To put that in perspective, that means that an Objective-C message send on the fast path (which happens 99.99% of the time, the slow path basically just happens once per message/class combo) costs about as much as two C function calls, or one and a half C++ virtual function calls. Message send overhead in a typical Objective-C app is small. 10% would be high, for really message-heavy code, and 5% is more typical. Most Objective-C code is not messaging so it's still fast. Take these benchmarks as an example. To write them in "idiomatic Objective-C" you'd change almost nothing. You'd either get rid of the few C++-isms (templates for min/max functions, parameters passed by reference, no big deal) or compile the file as Objective-C++. You'd never write code like this using Objective-C objects. In addition to be slower, it would be harder to write, harder to read, and much larger.
- chrisdevereux 13y ago
  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.

gmac 13y ago

Yes — in fact, it's arguably more natural in most cases to write your performance-critical stuff (e.g. math in loops) in plain C. There's rarely any reason to start boxing values up in NSNumbers and then unboxing them again. In addition, Apple's Accelerate framework makes it easy and natural to take advantage of SIMD for further speedups — you can get powerful vector operations with single function calls. This seems to have no Android equivalent.

pjmlp 13y ago
> This seems to have no Android equivalent. Renderscript?
- gmac 13y ago
  Thanks — previous Googling hadn't turned this up for some reason.

Someone 13y ago

"If these benchmarks were run on idiomatic Objective-C" s/idiomatic/pure/ I haven't programmed it much, but to me, idiomatic objective-C is when you use it as a sort-of scripting layer on top of your C code. No sane programmer would write ten layers of Objective-C message passing code; two or three is fine, on the bottom of your call stack (and hence, rarely executed)

mikeash 13y ago

Objective-C message sends always require a hash table lookup to resolve. That is the fast path. (Edit: almost always. I forgot about the vtable path for a few selectors. It doesn't affect most code and I don't think it's even used outside of x86-64, but it is a non-hash-table path.) However, implying that "require a hash table lookup" is slow isn't really right. The message send implementation is extremely optimized and takes about a dozen CPU cycles to execute last I measured. To put that in perspective, that means that an Objective-C message send on the fast path (which happens 99.99% of the time, the slow path basically just happens once per message/class combo) costs about as much as two C function calls, or one and a half C++ virtual function calls. Message send overhead in a typical Objective-C app is small. 10% would be high, for really message-heavy code, and 5% is more typical. Most Objective-C code is not messaging so it's still fast. Take these benchmarks as an example. To write them in "idiomatic Objective-C" you'd change almost nothing. You'd either get rid of the few C++-isms (templates for min/max functions, parameters passed by reference, no big deal) or compile the file as Objective-C++. You'd never write code like this using Objective-C objects. In addition to be slower, it would be harder to write, harder to read, and much larger.

chrisdevereux 13y ago
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.