Hacker News Reader

Comment by markus_zhang | Hacker News Reader

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.

What's your thought on this?

View on HN

Programmers that work on applications that don't work properly due to performance reasons don't optimize enough.

Programmers that work on applications that work properly spend the correct amount of time optimizing.

Programmers that work on applications that don't work or don't get finished may or may not spend enough time optimizing.

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.

I think the wisdom is to choose a better algorithm if you can, and choose a better implementation if you can't?

If it doesn't negativity affect the quality of the code & doesn't take a significant amount of time to do, then sure.

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.

(emphasis mine)

[0] https://www.jagregory.com/abrash-black-book/#understanding-h...

Replace all algorithms with O(n^2) complexity (or worse) with more efficient ones and you should be fine on modern computers, even with Javascript.

Poor algorithm choice can certainly overwhelm all other factors, but it's not that simple.

Sometimes it's not even possible to get any polynomial time solution, let alone quadratic.

Reply on news.ycombinator.com