-2

EDIT: I'm not asking for an opinion here. I'm not saying, "Let's debate what's evil and what's not." I'm saying if someone decides to just use static classes for a majority of their code, what performance gains does that give them? And what maintainability challenges does that represent?

I was reading an article today on how StackOverflow is able to be so fast using limited hardware: http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html

One thing that caught my eye is that they employ:

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

I've read opinions here and other places suggesting that Singletons and Static classes are "evil" -- that anything global is "evil". I've also learned that people who call things "evil" can be right in a situation -- but that they usually don't know what they're talking about.

So I'm turning to the community to understand this -- what advantages does StackExchange benefit from by using mostly static classes and methods? And what are the software maintainability or performance costs of their choices?

Community
  • 1
  • 1
Trevor
  • 4,620
  • 2
  • 28
  • 37
  • When you spend *too* much time optimizing code, you'll eventually end up writing C code. Yes, it is faster. No, somebody ought to stop you, it however is not our job to tell you to stop. – Hans Passant Apr 12 '15 at 23:41

1 Answers1

2

Using static methods and classes has two effects.

  1. Fewer null checks because a static method invocation does not require a null check on the receiver.
  2. Fewer allocations which leads to less memory pressure and time spent in GC.

Of course, this is at the cost of having fewer seams where you can break apart the system and do unit testing. Therefore it is probably more costly to maintain. It is not about what is good or "evil". They know the trade offs and they've decided that they want the performance more than they want the maintainability.

This blog post (also part 2) has a nice discussion of some of the performance trade offs they've made and it specifically discusses points in the article you've quoted.

Mike Zboray
  • 39,828
  • 3
  • 90
  • 122