Dynamic code generation at the call site means you can no longer share any code pages which contain message sends, so memory utilization goes way up unless you restrict this to app binaries and not libraries. But then most of your time is going to be spent in libraries, so the benefit will be much smaller.<p>Then there&#x27;s a question of how much space you reserve for the dynamic code. Since the rest of the code is built statically you can&#x27;t really shuffle things around, and have to have a hole where the code can be inserted. Make the hole too big, and you&#x27;re wasting precious I-cache space. Make it too small and you&#x27;re screwed. But you can&#x27;t predict the future very easily to know how big the message send code might be three OS revisions down the line.<p>On iOS you can&#x27;t write code dynamically at all in a normal process, so this all goes out the window. Your only choice there would be to generate inlining logic at compile time, and that has dire problems for binary compatibility.<p>objc_msgSend is pretty fast. I believe it&#x27;s currently around high single-digit CPU cycles per call on the fast path.