Anti-Patterns by Example: Premature Optimization

Software Engineering & Travel Journal

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet, we should not pass up our opportunities in that critical 3%

Donald Knuth wrote this quote back in 1973, and for over forty years software engineers have been debating its validity. Is it still applicable for nowadays?

Given the right proportions, it is. Premature Optimization is different than (Basic) Optimization. It is obvious, the key word here is Premature. Sahand Saba puts it nicely:

Optimizing before you have enough information to make educated conclusions about where and how to do the optimization.

It is preferable to write well designed and readable software first and then micro-optimize it later. Wait, micro?

Micro because you must be aware of using complicated and unproven “heuristics” instead of a known mathematically correct algorithm.

Another trap in this anti-pattern to be aware of is Randall Hyde’s sixth observation:

Observation #6: Software engineers have been led to believe that their time is more valuable than CPU time; therefore, wasting CPU cycles in order to reduce development time is always a win. They’ve forgotten, however, that the application users’ time is more valuable than their time.

Considering that you know what algorithm to pick, to over or prematurely optimize it is the real trap the Premature Optimization anti-pattern wants to warn you.

It is important to remember what Rico Mariani said, “Never give up your performance accidentally.” Notice he did not say, “Never give up performance.” He said programmers should not give up performance accidentally. People accidentally give up performance when they don’t understand the costs associated with the constructs they are using in their programs.

Examples in Real-Life

In BrightScript, Roku’s official language for developing channel applications, there are two list structures: roArray and roList. In fact, roList is a dynamic roArray.

Most of the time, when I need a list I won’t waste time choosing between those two: I will go straight to:

myList = []' creates a roList

Why wouldn’t I care 97% of the time, like Donald Knuth states? Because most of the time, my lists’ size is so small that any optimization in that scope is marginal.

However, I should be aware of what are the constraints of the software I’m writing. If I knew the list would accommodate a few pairs of elements and never grow in size, and if the sequence is in the heart of a process that potentially can block the render thread for too long, I would put more thinking on it.

But that does not happen more often than 3% of the time.


About The Author

Thiago Ricieri

I’m software engineer at Pluto TV, working on iOS, Android and Roku platforms. Personally interested in machine learning, algorithms, data science and tech industry. I travel a lot and take good pictures.

Add a comment

*Please complete all fields correctly

Related Posts

How IoT, Blockchain, AI, Machine Learning and more trends will shape 2018
The year has begun, and many topics keep getting attention from the community. You probably have stumbled with some of the following trends Gartner, HubSpot and Forbes. Check it out!
Services, Content Providers and MVP pattern
This week I got myself wondering when would be the best practical cases to use Services, Content Providers, and Model-View-Presenter pattern. Although the SDK Documentation provides a recommendation on when...
2017 was the Year of Subscriptions: a Rough Draft
What was a utopia years ago, today is commonplace. But it is not new: the internet has widely increased its adoption. Telecoms have always used this model. What is your...