Although I have heard a lot about the "Don't opimize if you don't need it" or many lines that are similar to this. I also heard from somewhere (maybe it was HN) that modern programmers do not spend enough time on optimization. Half because their education is more and more far away from low level and half because modern software is becoming too complex and they don't have time to optimize much.
Don't write code micro-optimizing each line of code as you write it, as prevalent in C and C++ circles, as starting point.
Rather think about the problem in abstract level, meaning data structures and algorithms for the problem being done.
For example if it is already obvious that the code section is going to work is large amount of data, doing linear search isn't going to scale.
Then also think about memory consumption, like maybe allocating all the time in a loop isn't the right approach, or if in a GC language that also supports value types, stack and global memory allocation, and off heap, consider where to place the data structures.
However don't over do it, and validate the assumptions with a profiler and the expectations of the end user.
An application doing batch processing overnight, no one is going to notice if it takes 5 seconds less with the algorithm that one has spent one week optimising for, other than the wasted developer budget.
On the other hand trying to do real time rendering at 120 FPS, every ms counts.
Don't prematurely optimize. Make your code work, make your code readable, and then profile your code.
Without profiling you're guessing where the most impactful work can be done. You don't want to spend a week shaving 150ms when you could have spent a day to make your program 10s faster.
Code quality is highly subjective though and often what some might consider as "high quality" also comes with a cost to performance.
Fortunately the linked book provides a simple way to decide when something needs to be optimized under "Understanding High Performance" [0]
--
Before we can create high-performance code, we must understand what high performance is. The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless.
Notice that the above definition most emphatically does not say anything about making the software as fast as possible. It also does not say anything about using assembly language, or an optimizing compiler, or, for that matter, a compiler at all. It also doesn’t say anything about how the code was designed and written. What it does say is that high-performance code shouldn’t get in the user’s way—and that’s all.
What's your thought on this?