4 ms·
I didn't mean to imply that messages are faster than JIT compiled calls. There's still at least one level of indirection in the optimal case, not sure about in
by sjs 16y ago
I didn't mean to imply that messages are faster than JIT compiled calls. There's still at least one level of indirection in the optimal case, not sure about in practice. However Dalvik being faster today doesn't mean that Obj-C is suddenly not fast enough. And when it's not fast enough you can make it so.
It's not as nice as it just being done automatically, the JIT is still preferable (imo). But when it comes down to Java vs. Obj-C, even with all the verbosity, I prefer Obj-C. Even at the price of typing stringByReplacingOccurrencesOfString:withString: and some (rare) manual optimization.
- KirinDave 16y agoI agree that the implicit argument is that ObjC isn't fast enough, and I agree that's an argument that needs some serious evidence before I'll take it seriously. But it is something to consider. Apple really hamstrung the freedom that having a c-friendly programming environment gave them with their new no-VMs policy. We were seeing great uses of things like lua and the door was open for LLVM, which really could have offered absurdly cool possibilities. As it stands, we'll just have to hope all this clang magic makes it into the next iPhone dev kit release. A better static compiler will help a lot.
- sjs 16y agoIt seems I misunderstood inline caching. If the call site itself is modified then it can be as fast as the JIT compiler. Interesting.