Does coding many small methods have performance ramifications for Objective-C?

Question

I come from Ruby, and have sort of adopted the methodology of single responsibility principle, encapsulation, loose coupling, small testable methods, etc., so my code tends to jump from method to method frequently. That's the way I am used to working in the Ruby world. I argue that this is the best way to work, mainly for BDD, as once you start having "large" methods that do multiple things, it becomes very difficult to test.

I am wondering if there are any draw backs to this approach as far as noticeable differences in performance?

Mason

What does this have to do with objective-c exactly? – Dinette

In general: you don't need to worry about this. More important is to design your architecture for performance from the beginning. If performance issues come up in practice, you can add optimization. For example, IMP caching to avoid dynamic method lookup in hot code. – Dugas

This is a "whiteboard" question and would probably fit better on Software Engineering. Additionally, although you've implied that you're working with and asking about ObjC, it's not really that clear why you expect performance impact from that language as compared with Ruby or anything else. I've left the tag, but this could be made much more concrete and specific. – Dodwell

Worth checking about function call overheads, publib.boulder.ibm.com/infocenter/macxhelp/v6v81/… – Ferrochromium

Answer 1

Yes, there will always be some amount of performance impact unless you have a compiler that inlines things, but if you do dynamic method lookup (like Ruby and Obj-C), you can't inline, and so there will be some impact. However, it really depends on the language and the calling conventions. If you have a call in Objective-C, you know that the overhead will be the overhead of of using the C calling conventions once (calling objc_msg_send), then a method lookup, and then some sort of jump (most likely also C calling conventions, but could be anything). You have to remember, though, that unless you're writing C and assembly, it's almost impossible to see any difference.

Copley

JITs can inline (and later undo that if it becomes a problem) dynamic dispatch though. – Shamikashamma

@delnan: Good point, but Obj-C is not JIT, and neither is Ruby. Ruby is interpreted, and Obj-C is compiled to machine code. – Copley

Currently, Objective-C methods are never inlined because even when using normal message dispatch ([foo bar];) the method can be replaced at runtime, so the compiler can't know exactly what code to inline. – Impenetrability

Yeah, I was speaking in general, not for ObjC specifically. – Shamikashamma

Answer 2

While not necessarily Object-C specific, too many method calls that are not inlined by the compiler in non-interpreted or non-dynamic-dispatch languages/runtimes will create performance penalties since every call to a new function requires pushing a return address on the stack as well as setting up a new stack frame that must be cleaned up when the callee returns back to the caller. Additionally, functions that pass variables by-reference can incurr performance penalties since the function call is considered opaque to the compiler, removing the ability for the compiler to make optimizations ... in other words the compiler cannot re-order read/write operations across a function call to memory addresses that are passed to a function as modifiable arguments (i.e., pointers to non-const objects) since there could be side-effects on those memory addresses that would create hazards if an operation was re-ordered.

I would think though in the end you would only really notice these performance losses in a tight CPU-bound loop. For instance, any function call that makes an OS syscall could actually cause your program to lose it's time-slice in the OS scheduler or be pre-empted, which will take exorbitantly longer than any function call itself.

Adair

so, doesn't that sort of go against good OOP design? I mean, when I think of a robust, scaleable OOP design, I think it probably is going to require a lot of method calls..... – Mason

Well, I specifically stated non-inlined functions ... for instance, in C++, the compiler can inline a lot of smaller getter/setter methods, etc., keeping the performance of OOP fairly close to optimal. – Adair

Actually, C++ compilers specifically can't inline a lot of methods due to separate compilation -- templates obviously excluded. Some toolchains (such as LLVM) embrace link-time optimization though, so this can be alleviated if you care to. – Shamikashamma

If you include the getter/setter method in a header file though, and mark it as inline, that should hint to the compiler, with proper optimization levels enabled (i.e., g++ -O2), to inline those methods and avoid the function-call overhead. – Adair

Answer 3

It is true that there is some performance impact. However, the performance of most systems is dominated by I/O, and so method dispatch overhead is a small part of the performance picture. If you are doing an app where method dispatch overhead is significant, you might look into coding in a language with more dispatch options.

Palate

Answer 4

Method calls in Objective-C are relatively expensive (probably at least 10x slower than, say, C++ or Java). (In fact, I don't know if any standard Objective-C method calls are, or can be, inlined, due to "duck typing", et al.)

But in most cases the performance of Objective-C is dominated by UI operations (and IO operations, and network operations), and the efficiency of run-of-the-mill code is inconsequential. Only if you were doing some intense computation would call performance be of concern.

Kingship