2

I read this article about https://stackoverflow.com/ and note this sentence:

Heavy usage of static classes and methods, for simplicity and better performance.

My question is,Is there any difference between static and singleton performance? And if there is why?

Community
  • 1
  • 1
  • I'd offer my usual advice - set performance goals, write clear, understandable code, and then *measure* the performance. Only if the code doesn't meet the goals should you investigate and isolate *where* the performance issue is, and start considering alternatives. Don't try to learn a billion rules for writing "high performance" code and, here, don't adopt a particular coding style just because "that's how SO code" - they do it for specific reasons, and for specific scale - is it likely that your situation is identical to theirs? – Damien_The_Unbeliever Sep 23 '15 at 12:25

2 Answers2

3

There's little difference. As always, if you're in doubt, profile - but I severely doubt you'll find anything interesting.

Static methods have three main advantages:

  • No need to pass the implicit this
  • No virtual method calls
  • No null-checking

Virtual method calls are avoided by not using the virtual keyword and by not implementing interfaces. They are also evaluated in runtime and optimized away if possible.

Passing this may be tricky for structs, but that's not how you'd usually implement a singleton. For a normal reference type, this is likely a simple pass-by-register reference.

The last point should also be obvious - due to the contracts in C#, if you try to call a method on a null reference, you're supposed to get a NullReferenceException - even if the method doesn't actually use this at all.

However, performance isn't the only useful metric. If you think about it, static classes and static methods are little different from functional modules and functions. I think this is what the original article is alluding to the most - if done right, functional programming is a lot simpler than trying to fit your code into some arbitrarily defined classes. I'd assume that while there's plenty of static methods (functions), there's few static fields - and state changes can be tricky to manage and understand, if they get out of hand. This applies doubly for shared state, and you'd be hard pressed to find some state that is more shared than a public static field.

Again - performance is just one thing. Software development is a balancing act, and it doesn't do to focus on one metric. If you focus too much on (low level) performance, you might be missing out on maintenance and readability, and even on high level performance optimizations. If it's crucial to avoid overheads, go ahead - use static fields and static methods. If you need to handle 10k requests in parallel, you'll likely need a lot of low-level optimizations. But make sure you know it's usually a trade-off.

Luaan
  • 62,244
  • 7
  • 97
  • 116
  • can u explain No need to pass the implicit this? –  Sep 23 '15 at 12:07
  • @Shahrooz Well, when you call an instance method, you need to pass `this` - the instance. Static methods don't have that - they're not tied to any instance. However, I need to point out that if you have to ask this, *forget about any performance difference*. You're not anywhere close to where advice like this is able to do you any good - stick to the good, clean practices, until you understand how things work under the cover well enough. – Luaan Sep 23 '15 at 12:09
  • Can u tell me a reference? –  Sep 23 '15 at 12:12
  • @Shahrooz A reference for what? C# language specification? – Luaan Sep 23 '15 at 12:13
  • @Shahrooz You still didn't tell me *what* you want a reference to :) I can share a lot of links, but you probably have something specific in mind? :) – Luaan Sep 23 '15 at 12:18
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/90439/discussion-between-shahrooz-and-luaan). –  Sep 23 '15 at 12:52
0

If you're implementing your singleton correctly then i would say there is no performance difference.

The only difference is with a standard static you leave the system open to creating new instances whenever you want, where as a Singleton enforces that it is only created once.

CathalMF
  • 9,705
  • 6
  • 70
  • 106
  • How can you "leave the system open" to create new instances of a *static* class? If anything, you have this entirely backwards - it's *theoretically* possible to create multiple singletons, while the question of instances doesn't even make sense for static classes. – Luaan Sep 23 '15 at 12:19
  • @Luaan Ok maybe a bad choice in terminology. Basically with a static you can still do MyStaticBleh = new MyClassHere();. You cannot use NEW with a singleton because the constructor should be private. – CathalMF Sep 23 '15 at 13:18
  • Static classes do not have public constructors. I really have no idea what you're trying to point out here :D Note that nobody was talking about static *fields* - that might be the confusion here. – Luaan Sep 23 '15 at 13:27