15

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.

Cris
  • 250
  • 1
  • 8
  • 1
    Mike Ash has some a pair of nice posts showing numbers for [Leopard](http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-leopard-edition.html) and [iOS](http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-iphone-edition.html). 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 '11 at 00:50
  • 1
    If you want to avoid that overhead, use C functions. –  Oct 26 '11 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 '11 at 19:38
  • See [Cost of message dispatch in Objective-C](http://stackoverflow.com/q/907843/643383) on SO for some good answers. – Caleb Oct 27 '11 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 '11 at 20:34
  • @Caleb: I guess I'd need a like-for-like comparison (varying only method length) for that to be extremely meaningful. You make a fair point, and certainly I'd like to make time for such an exercise; OTOH much of the purpose of asking questions is to gain from the experience of others. – Cris Oct 27 '11 at 22:43

2 Answers2

4

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

Jordão
  • 651
  • 6
  • 7
  • 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 '11 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 '11 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 '11 at 20:19
2

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.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176