Is performance a sufficient reason for having a singleton or static class?

Question

I have class that I believe should not be a singleton or static class. It has state, albeit state that could be shared by consumers. I like to stay away from singletons when there is shared state, but the argument I'm hearing is that I will reap performance benefits from only ever having 1 instance of the object exist at any given time.

In my particular case, there is not a lot of data associated with this object -- two dictionaries with (at max) 150 entries in each and the dictionary.

At what point--if at all--does the performance argument hold any merit?

FYI - I'm using .NET.

Thanks!

Answer 1

I don't think performance is a very strong argument, either for or against using the singleton pattern. It's a design issue, either it makes sense to use a singleton, or not:

If you need exactly one instance of the object, use a singleton.

If you need multiple instances, don't.

Answer 2

No. The performance argument does NOT hold any merit.

You should benchmark and confirm/identify a performance problem, before assuming you have one. 9 times out of 10 it won't be where you thought.

If a Singleton is required, it simply is.

Answer 3

The singleton pattern exists mostly to allow you to specify that you only ever want one instance of the class. Static classes are generally used to provide stateless behavior. What you are describing does not really seem to fit either category. I'd investigate using caching rather than a singleton pattern to improve the performance of the code. Of course, your cache may be a singleton, but in the case of a cache it would make sense.

Of course, if your object is a cache, then I've just talked myself into a circle.

Answer 4

You shouldn't think about creating a Singleton (or a Static class) for performance reasons.

You either need to make it a Singleton by design, or you don't. If multiple instances of your class should exist and be different from each other, then you can't use a singleton.

Answer 5

If there is a large cost to construction, then you would probably be better suited to an Abstract Factory pattern that returns a common instance. Singletons have a bad reputation, particularly with the TDD crowd, but effectively AF and Singleton can do the same thing (AF can do more, but that's a different story).

Since you don't have a large cost, then it probably doesn't matter.

Answer 6

Usually, a singleton inhibits performance, more than anything. It means you have to wrap the class in locks and synchronization in a multithreaded application. That could possibly have been avoided if singletons or globals had not been used.

So a singleton may be slower, but I can't think of any situation where it'd be faster.

If you want your application to share a single instance of an object, then pass references to that object around. That also leaves you flexiblity to change the design later, when it turns out that for caching or concurrency reasons, using multiple separate instances would actually have been faster.

The most important thing to remember about performance is that it's hard to predict. No matter what you guess your bottleneck is, you're almost certainly wrong. So the best way to ensure good performance is to make it easy to modify your program. Singletons work against you there. Once you have a singleton, it is almost impossible to remove. You're stuck with one universal instance of the class, even if multiple instances would have performed better, even if local variables instead of a global singleton would have improved cache usage.

Answer 7

You should use a Singleton only in cases where there can conceptually only be one instance of an object, not to artificially restrict the developer to one instance. If there could possibly be two instances then it shouldn't be a Singleton.

If the former is the case, and there is state associated with the object, then a Singleton is useful if there is substantial cost associated with initialization and either a chance the class will never be used, or a reason to defer the initialization. In that case a Singleton is good. The alternative us a static class, and you should use it whenever the above doesn't apply.