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.

OpenAIDealAccountDeleted
  • 250

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
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,502