Why Optimize Code for Performance

Here is the answer.

This is a question I get from time to time.

Some developers are convinced that optimizing code for performance is overrated especially when we know that hardware is getting so powerful day by day.

However, other developers think that the answer to this question lies in the question itself; simply because we want our applications to perform the best.

I think I know where the confusion is coming from. Both sides have some of the truth but they are confusing something to another. This is what we are going to discuss in the next sections.

---

Premature Optimization

It is the excessive, uncalled-for, time-consuming optimizations. In other words, it is the kind of optimization which consume too much time and effort to optimize a piece of code without actually having a good reason.

This kind of optimization should not be accepted in the world of software developers as, besides being too expensive, it opens the door wide to anti-patterns and bad practices.

This is because these optimizations are most probably focused on low-level code analysis. You start examining the code line by line figuring out how each line would be translated into machine code and then you start designing your high-level code accordingly. Is this something good?

The short answer is no. In order to achieve this level of control, you might violate too many best practices so that you can get the kind of minor optimizations you want.

For example, you might think of dropping abstractions. Why?

Because when the compiler deals with design time classes, it knows how to apply optimizations like which method implementation to call. However, when it deals with abstractions like interfaces or abstract classes or even virtual methods, it is not able to apply these optimizations and it then needs to postpone some evaluations to the run time, which is for sure less performant.

Having said that, back to our main problem, developers confuse Premature Optimization with what is called Performance Abiding Practices.

---

---

Performance Abiding Practices

These are the practices that are proved to be efficient to the extent that they are considered defaults.

For example, once we know that using StringBuilder is much better and performant than using string concatenation, it is not acceptable to use string concatenation just because we are not sure yet if we would need to apply performance optimizations. This is not an acceptable excuse.

Also, once we know that using the sealed keyword is proven to be a best practice from the design and performance point of view, we should also refuse not using it for the same excuse as above.

Note: If you don’t know much about the sealed keyword and how it could yield a performance boost, you can read the article Compiler-Friendly Code: Sealed Keyword in .NET C#.

Our goal should always be to follow these best practices unless there is a strong reason not to.

---

Why Optimize?

Optimize because in the software world, there is always something new. What you think is enough today would not be in a short period of time.

What your software system offers today might be good, but your customers’ needs grow day by day, and to keep up with the new needs, your system needs to expand and adapt. However, if your system is not built for being a highly performant system, you would hit a brick wall stopping you from expanding.

Additionally, your software system is not the only system out there. You have competitors and to be able to win the race, you need to always be ready and growing. What could actually stop you from doing this is having a low-performing system.

Therefore, optimizing your software system is not a luxury, it is a need.

---

Final Thoughts. Photo by Kenny Eliason on Unsplash, adjusted by Ahmed Tarek

Final Thoughts

My advice, keep an eye on your system needs and always try to follow the best practices. Whenever you spot a bottleneck in your system, you can then investigate and act accordingly.

Hope you find reading this article as interesting as I found writing it.