3 ms·

Sure but that would probably be about as performant as: `(objc_lookupImp(obj, sel) ?: objc_nilImp())(obj, sel, ..params..)` (I realize you said "if you don't c

• simscitizen 13y ago
  iTunes and other Apple software on Windows runs with code that looks pretty much exactly like that. Those code bases are compiled from Obj-C into plain C by the objc rewriter module in clang, then compiled into machine code by Visual Studio. You can take a look at what the clang rewriter does here: http://clang.llvm.org/doxygen/RewriteObjC_8cpp_source.html http://clang.llvm.org/doxygen/RewriteObjC_8cpp_source.html
  • pavlov 13y ago
    That's very interesting, I've never heard of that (but assumed it would be something pretty much along those lines). What's the Obj-C runtime used on Windows for those apps? Is it a descendant of the NeXT runtime which did run on Win32 at one point, or something else?
• to3m 13y ago
  That approach, if inlined, #define-style, for every message send, would probably be better than going through objc_msgSend. Since each method call then gets its own branch instruction, rather than every single last one sharing the one jmp at the end of objc_msgSend, you'd get less branch target history contention. Most message sends end up at the same place each time, most of the time, so I'd think this is what you want. But whether it's actually an issue in practice I couldn't say, and if nobody's done it already I suppose it could not be...