I generally favour using small methods, as recommended by, amongst others, Bob Martin in Clean Code. I've also read enough about Objective-C's internals to have at least some idea about how its message dispatch works (bbums series is particularly informative on this).
Premature optimisation concerns notwithstanding, I'd like to know if all that work that Objective-c does with objc_msgSend is, in practical terms, significant enough for the 'many small methods' approach to be inadvisable for Objective-C projects.
Empirical findings are particularly welcome (maybe I'll set up a test myself sometime). Experience from anyone who has written large objective-c projects would also be great.
Clarification
The general tone of the question is intentional. I'm not asking about performance tuning of specific apps (which is why I ask here rather than on SO), but more about whether Objective-C's language characteristics discourage a certain design approach. I have observed that much of the code I've seen from Apple, and other parties (on github etc) tends towards large methods (and classes), and I'm wondering if this is a bias that has crept in because of the language itself. Of course I may have been reading the wrong code, or it may be cultural rather than technical factors that have led to the tendency if it exists.
(For what it's worth, I am currently writing Objective-C, and I'm using small methods)
Further request
I agree with both the answers that have been given. One further thing I'd like is for someone to point me to a (hopefully substantial) open-source (or otherwise visible) Objective-C codebase that uses nice short methods (and small classes). I haven't seen anything in Objective-C yet to compare with (for example) the fitnesse source.
Best Answer
I don't really know whether the overhead is negligible or not. But, I would prefer to design a system to be easily understandable and maintainable first, and that normally means small, focused methods and classes. This will even help with subsequent code tuning too (just because the code is more maintainable). Also, it's important to profile the code to find real bottlenecks, which might not even be related to method call overhead. If you do any off-process operations (e.g. calls to database, network, file system), these tend to dominate the runtime of the program anyway.
But, as usual, your mileage may vary...