Question

This is a general objective-c / iPhone question:

If I have a large method, is it better to create a single class and call the method from other classes or just re-write the method when I need it in each new class? I’m asking not from a code reading perspective, but from an iPhone performance perspective. Does the compiler care? Does anyone have evidence of singleton subclassing being significantly faster?

Answer 1

There is no satisfactory generalized answer, whether a singleton is faster than multiple instances.

I’ll talk about shared instances (not singletons).

You can make some higher level generalizations with shared instances.

If your object has no mutable or thread critical state, then you may reduce the number of objects you create by sharing that instance. In that case, you will reduce the number of objects you create (whether that should be a concern in your particular case is unknown).

Similarly, if you have found a problem, you can often reconsider class designs to reuse and share appropriately for the problem you have observed. This would often consist of dividing a large class’ mutable state from its immutable state, and sharing the immutable pieces among transactions. This technique is often reserved for more advanced problems, and might happen a few times in a moderately complex iPhone app, but is not often a problem people consider worthy of correction in small apps as the developer did not consider it an issue worth their time.

If your objects have state or must operate in a thread safe manner, then you may want to appropriately reconsider what needs to be shared, and what does not need to be shared. This also varies wildly by how your program executes.

So, let’s say we have a:

• single shared instance which formats dates for you
• and that the object has some internal mutable state where it holds transient results (not necessarily a good design, but…).

Would a shared instance help?

Compared to creating a new instance every time? Yes. You would create far fewer transient objects. This could cost more than the calculation itself.

In a heavily multithreaded context with many dates to transform, compared to having one instance per thread? No. You would need to lock, and the clients from all threads would be competing for the same resource. Your program would be faster if it were not multi-threaded. The good (general) solution in this case would be to create one formatter instance per thread to process all those dates, removing the need to lock the formatter while it processed each date.

The high level question in the OP has no correct answer without context. You also need to understand your program and your problem well, and choose the right approach to the problem. The problem (or lack of a specific one) should not be an excuse to create a singleton.

In general, I’d say that you should focus on good design first, but also be aware of your program’s execution problems and learn from them. Many developers who wait until there is a noticeable performance problem do not recognize (and consequently learn from) their past mistakes. So it helps to go in every once in a while and profile your app and learn how to improve those problems that arise, even if there is no “obvious performance problem”. Poorly constructed designs also have so many performance problems that the signal to noise ratio of a sample/profile will not be very useful — there will be many less than obvious issues, and many may be difficult to correct after the fact. By profiling and learning how to write optimized programs, you will be aware of performance considerations in advance, and avoid and recognize them next time you write a program. It will also take less time to recognize problems which arise in the future.