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.


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.

  • 1
    Mike Ash has some a pair of nice posts showing numbers for Leopard and iOS. I haven't digested these fully, but it would seem that for cached IMPs the overhead is negligible, and even in dispatches requiring search, it's pretty small. If this quick impression is right, it would seem that small methods might stand or fall on the same design grounds in ObjC as in any other language.
    – Cris
    Oct 26, 2011 at 0:50
  • 1
    If you want to avoid that overhead, use C functions.
    – user4595
    Oct 26, 2011 at 16:06
  • Technically possible, but a lot's lost with functions. I would only replace methods with functions for targeted, performance-sensitive portions of code. I'm asking here about whether the overhead is problematic enough to reconsider a preferred coding/design style.
    – Cris
    Oct 26, 2011 at 19:38
  • See Cost of message dispatch in Objective-C on SO for some good answers.
    – Caleb
    Oct 27, 2011 at 15:48
  • Why you don't simply profile your code in Xcode? I understand that you're asking in the abstract and not about specific code, but since you've apparently got some code with lots of small methods, why not run it and see for yourself?
    – Caleb
    Oct 27, 2011 at 20:34

2 Answers 2


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...

  • Of course I agree with all of this (see the 'Uncle Bob' ref in the question). But if a language didn't lend itself in general to a certain best-case design approach, programmers might make other choices. I have not seen much Objective-C code that really follows the small methods (and classes, for that matter approach), and am wondering why. I'll add a note to the question.
    – Cris
    Oct 27, 2011 at 20:02
  • @Cris: "I have not seen much Objective-C code that really follows the small methods" -> Just curious: from what body of code did you draw such a conclusion? I believe in it, but I also believe that it's not because of micro-optimization awareness, but more of programmers not focusing on the tenets of good design and maintainability. Putting it another way, their Java, C#, Ruby or whatever code must follow the same practices...
    – Jordão
    Oct 27, 2011 at 20:05
  • Yes, that's quite possible. I didn't have any specific codebase in mind; just what I've looked at over the year or so I've worked with Objective-C. The largest set of code I've looked at was the Omni group's open-source stuff, and IIRC that had lots of big methods. Apple's sample code also often does. But of course (a) sample code is just that, and (b) my sample may be weighted towards UI code, view controllers in particular, and these may be coded differently from the deeper layers.
    – Cris
    Oct 27, 2011 at 20:19

The vast majority of code is not going to be performance-critical in any application, so even if the method overhead were significant compared to other languages, the optimal approach would still be to have many small methods in most places and inline only those that profiling has shown to be performance-critical.

Of course, there are many people who don't know how to optimize properly, and of those some may know about method overhead and engage in acts of global premature optimization, but I do not believe that group is large enough to have a significant impact on the Objective-C ecosystem.

Large methods and classes are far more likely to be the work of the large group of people who know or care nothing about profilers, method overhead or proper design, and who will tend to produce Big Balls of Mud in any language. And yes, some of those people do work on high-profile codebases in major software companies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.