Writing clean, performant code for the iPhone

Question

I have been developing on the iPhone with Objective-C for a few months now and I have been applying the best-practices learnt and refined while developing applications with Java. These include: designing classes that have a single responsibility, application of design patterns where appropriate, and writing short methods that do one thing only. To me these practices are both beneficial from a clean-code perspective and are largely domain agnostic.

I have been quite happy with the results. However, a few iPhone developers have independently advised me against this as they say I write too many classes and too many methods. At various times I have been warned:

• The stack will blow
• Too many classes will slow the iPhone down (i.e perceptible by the user)
• Nested method calls will hurt performance (i.e perceptible by the user)

In practice I haven't experienced these issues. Looking superficially at some iPhone performance metrics it seems to me that the extra method calls and object life-cycle overhead required to implement common patterns and short methods is unlikely to create any user perceptible delay. However, the advice from other iPhone developers has me spooked a little.

I would like to continue learning and refining the domain agnostic programming practices that have served me well in the past, but when developing on the iPhone I don't wish to head down a route that will end in pain!

So with regard to this platform - should I forsake some common best-practices and be more conscious of optimizing method call and object life-cycle overheads? Or should I continue following Knuth's advice:

Premature optimization is the root of all evil (or at least most of it) in programming

Answer 1

For me it really does come down to maintainability. with good quality code you can maintain the system so much easier.

I have developers who work with me and when i suggest they take short cuts to make a system work, they scorn on me and deliver the project late. and it has paid in the long run every time!!!

if it is an intensive app, using opebGL and what not then performance might become an issue. if it's just a simple utility or data app. i would recommend contiuing with the best code practices you know, and then keep learning them as they are invaluable. Most patterns are domain agnostic and beneficial across all fundemental programing languages.

And if you do blow the stack, then re factor some of those methods/classes into single calls (at least you know it might happen and will notice it as soon as it happens) And if it doesnt then you have awesome code to maintain that is easily readable by any half baked code monkey who has to look at it latter.

Answer 2

The whole problem with OO apps slowing down is simply that object can spiral out of control more easily than structured programming styles. Once upon a time, before method call optimisations were improved, this could make a difference, especially when indirect (ie virtual) calls were made.

If your objects are used a lot, and you have some lower level objects that you call often, then you might perhaps get a performance hit from using them - but I'm talking about millions of calls (I've seen some horrible code in my time, both unstructured, structured and OO!). You will also get more of a performance hit if you allocate and delete lots (LOTS) of objects continually.

The only answer really though, is to take a look. If you have an object that gets allocated, deleted in rapid succession, then optimise it away (even if it looks less elegant), if you have an object that you call its methods thousands of times, then optimise that away too. (but once you've done this measuring, you'll have measured its performance and you'll be refining the slow bits!)

There's a trade off between 'elegant' code and code that works simply and quickly, don't go to either extreme and you should be fine.

Answer 3

I had a similar experience when developing a rather complicated Blackberry application. I, too, was told to avoid frequent object allocations, inner classes, etc. The original application we had was an unmaintainable mess. I recently rewrote the application with a focus on good OO design (patterns where needed, lots of single-purposed and often immutable objects, etc.). In a lot of places, I violated the advice of avoiding certain "costly" constructs and object allocations. The resulting application was not only easier to maintain, but was also smaller. If the extra object allocations created any overhead, I certainly didn't notice. I think the lesson here is exactly what Knuth said. Focus first on good design, then optimize if needed. In addition, these mobile devices nowadays have enough memory to where this advice will hopefully fall out of favor...

Answer 4

Generally speaking: don't worry about it. The only case where using objects and messages could be a potential performance issue is where you are doing hundreds or thousands of allocations at once, or doing thousands of message sends every few ms. You wouldn't want to use Obj-C objects to represent thousands of 3D vectors in a physics simulation.

Even in the case where you are doing lots of message sends in a loop, you can get better performance by storing a function pointer to the appropriate method before the loop.