#007: Let’s Talk Optimization
Let me start by saying that premature optimization is the root of all evil. Just because you can do something, does not mean that you should! The Pareto Principle (80/20 rule) applies here: often, a large share of a program’s performance depends on a relatively small portion of its code. The rest can become a distraction, full of minor inconveniences. More often than not, intrinsic properties and characteristics, such as the choice of data types and algorithms, have a bigger effect on performance than a lack of optimization.
The reason I can say this so confidently is that I have personal experience with this exact situation. One of the most frustrating parts of writing code is when everything looks correct, but the program still refuses to work properly or as expected.
There’s no error message, and staring at the same five lines of code takes you nowhere. At that point, you are in a state referred to as “softlocked” in gaming communities.
But it is important to remember that, unlike games where there’s only fixed options, real life is quite expansive. If, at first, you cannot find the issue, you can simply start by mapping out EVERY SINGLE THING.
Taking stock of the situation can have a similar effect to talking about your problem with a therapist. Quite frequently, a simple change in perspective and understanding of the situation is enough to figure out the issue. By mapping important information, such as the time spent in each function, you can backtrack efficiently through the code and perform targeted surgery at the site of the trouble.
Debugging slow speeds can often feel like a battle that you are not prepared for. But approaching it systematically, step by step, makes the task of solving it much easier! The more experience you gain, the more you realize that optimizing is rarely about randomly trying moves. Instead, it is based on thoroughly understanding the situation before making targeted improvements.
I have found that the best approach is to slow down and ask a few simple questions: What did I realistically expect to happen? What happened instead? Can I figure out which part of the code is actually taking the most time? Is there a possibility of improvement? If not, what is the next biggest issue?
Breaking a large problem into smaller pieces makes it much easier to find the real source of your bottleneck.
Sometimes, the problem can simply be a bug caused by a complicated logic error (and once you fix it, you feel like smacking yourself)…
Other times, it is simply caused by calling a function with heavy overhead inside a loop when it could instead be called once, outside of it. That’s usually much simpler to find out and address. In actuality, it’s often a combination of the two.
Either way, every optimization teaches you a little more about how your code behaves in the real world, and it is this knowledge that fuels your future optimizations.The goal here is not to write code that is lightning-fast without anything meaningful to show for its speed. That would be putting the cart before the horse.
The real skill is learning how to stay calm and focused, investigate carefully, and keep trying different, but structured, approaches until the problem finally gives you an answer, without wasting too much time.
Small optimization checklist
- Ensure you really NEED to optimize.
- Reproduce the slow behavior consistently.
- Measure everything before changing anything.
- Identify the function or operation taking the most time.
- Change one thing at a time and compare the results immediately.
- Confirm that the improvements did not break anything else in your code.
There is no shame in getting stuck on a performance problem. Sometimes, working through one difficult debugging session gives you more experience than writing a dozen lines of code that worked perfectly on the first try. Only when you try, will you be able to make progress. And once you do, you’ll find the same joy in it as a mechanics do when they fix a car.