Hacker News Reader

Ya that paragraph is ripe for cherry picking that often quoted nugget. But right after it is "we should not pass up our opportunities in that critical 3%". And further along, "the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail." That one I think is the most important. You don't even know what you should optimize until you measure. You could end up spending a lot of time and energy on the wrong problem.

It's like the problem is the ambiguous definition of "premature".

I think by itself the phrase is taken to mean to keep the code high level and abstract as long as it might still need to change, and then only optimize once it's overall structure is established, because once you start optimizing for performance you are carving stone and destroying flexibility.

But the full context shows that the word "premature" in this context means to say that it's premature to optimize before you even know what to optimize.

Those of us who have been doing this a long time develop an awareness of our "hot path", and defend it against encroachments. Work keeping speed bumps out of our hot path is not premature.

Performance is not a primary objective for most software. For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later.

People that have been in the performance business a long time, the kind of people you want if performance matters, can estimate the performance of code without running it to a degree of accuracy that is surprising to people with no performance engineering experience. Not understanding the relationship between code and performance is not the same as no one being able to understand the relationship between code and performance. It is a specialized discipline but people in it don't need to measure code for macro-optimization purposes. You still need to measure some things for micro-optimization purposes, but even there you'll find savants that really don't need to.

Naturally, there is an element of many developers overestimating their ability to estimate code performance. That is not universal though. I've worked with developers that could consistently and precisely describe the performance characteristics of code on real hardware without running it. A lot of computer science is premised on this being possible. Acting like this is unknowable is doing a disservice to computer science as a discipline.

If you understand how code interacts with hardware then performance is deterministic and obvious. There are degrees, of course, but some developers have a deeply intuitive understanding of these relationships.

> For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later.

This conclusion is strange to me. Literally every performance improvement I’ve seen is done at the end of a project. Of course you try to avoid architectural defects, but software is not immutable. So you punt the performance work later in the cycle once a) you’ve verified the approach overall roughly works b) you’re confident you have a handle on the business needs c) you have identified a need to improve performance. Any performance defects that turn out to be architectural in nature are still fixable, just more expensive (hence the desire to fix the most obvious ones). For example, look at any piece of Google infrastructure. They always go through several iterations because it doesn’t matter how good your intuition may be. You can still be wrong and the landscape isn’t static so whatever was right at the time may have evolved to not be as right. For example, protobufs made the right choice about encoding for space when bandwidth was more limited. Now that bandwidth is much more free and compression is more effective, it’s better to use compressors instead of trying to find a more optimal binary coding.

Of course it is not the best use of time to optimize from day one if there is no need to have this piece of software to be fast/efficient, but if performance is an important requirement it's too late to add it at the end. You cannot optimize Apache 1.x to handle 1M concurrent connections and 1M request per second (without rewriting it more or less fully). Nginx can handle such load on a single modern server because attention to performance (efficiency) was paid from the start of development.

If performance is awful to begin with you can improve it visibly by fixing a few hot-spots (like unnecessary O(N^2) for N which can be large). But when I do profiling for software which is not too bad to begin with there usually no single place which can be changed to give statistically significant improvement - there are many comparably slow places. One can try to improve them piece by piece but sooner or later abstractions will get in the way and if performance is still not enough you'll need to start from scratch keeping performance in mind.

Depends on the size of architectural changes needed. I've worked in industry a while though and architectural changes to enable better optimizations happen all the time. You can't know you need a v2 until you've built v1 and understand what the problems with v1 are in production / where things fall down.

Perhaps a better understood paraphrase: Never guess at performance, and don’t measure for performance until the application works.

1st part. YES. 2nd part. NO. If your end goal needs to meet a certain mark then you need to be measuring as you go. If you are headed down the wrong path, by not paying attention to perf you'll end up bogged down rewriting systems that 'work' but they were never going to be fast enough. I've been through this headache too many times now to not get a little irritated when projects don't keep perf and memory usage on the same importance as 'working'. This often manifest by developing on much more powerful hardware than will be shipped on...

All you need is the measure part. Then you won't do the evil thing of optimizing something that makes it more brittle and hard to maintain etc.

Well it’s not like you don’t keep it in mind. Your project has some baseline performance need and you should be building with the common practices and paradigms you used to build the other parts. The point is, don’t try to guess which part might need optimization tweaks. Write it first and then prove you need to spend extra time improving something.

But don't write it all first, that is don't wait until your shipping. I mean if you are trying to be first to market maybe that changes things. Everyone's developing different things in different markets but in my experience developers tend to hold onto that particular mantra, and it turns into wait until the last minute to actually check perf. See other comment about the immaturity of the industry which I agree with.

I agree in theory but not in practice. Most developers have no idea how to measure the performance of a software product either in code units, libraries, features, or the product as a whole. Worse, they really have no idea what to measure. This is even after you’ve passed that tremendous hurdle that you need measurements not assumptions.

A large part of that is due to the immaturity of software as a profession relative to other professions. Measuring things takes tremendous effort and many developers don’t want to challenge their deeply held assumptions of how things work. Often when you present performance measures to developers they will invent an excuse to throw the data out if they don’t like the conclusion.

If performance matters, you hire the subset of programmers who do have an idea about performance, and who even get it right before measuring.

Sigh, this is true.

Better training and better tools can help make obvious their mistakes but I don't know how to combat the dogma. I've often been shocked how almost superstitious developers are - you'd think developers would have a more scientific approach but they are just as likely to chase after ghosts than optimize what needs to be optimized.

Wrap a timer around your tests, there that is measuring something!

So 90% of programming is crap? (Sturgeon's law)

Seriously though, there are plenty of developers who can cautiously evaluate performance as they go. It's just that it's not a super common skill (nor is writing low level code, etc), but it exists and is happening all the time. Game devs for example.

He's making a more general statement, with "root of all evil", that improving some aspect of something without understanding its effects on the whole outcome, is literally the root cause of evil in the world, in general. Winning the battle but losing the war. Not seeing the forest for the trees. Getting lost in the weeds. Unenlightened self-interest. Not hyperbole, but a particular instance of a general concept.

But on code optimization, k deeply nested loops are not a bad guide to O(n^k), and a candidate for optimization.

That said, I once cached something that obviously needed to be cached - so obvious in fact that a deeper level in the system already cached it.

But even that has to be taken with a grain of salt. There are kinds of critical code that are hard to identify. Think of the infamous O(n^2) algorithms which are not identified unless you measure high values of n. Or not well coordinated threads that slow down a programm only on specific occasions.

Yes, but conversely, there are cases where O(1), O(N) and O(N^2) are all perceptually the same in all cases of a particular program. There's a bit of an art to determining what is critical and non-critical.

I agree. This is immature optimization.

Back to ”Premature optimization is the root of all evil”: I think that’s a bad statement. The only thing that says something there is all, and it is incorrect.

“Premature (noun) is the root of evil” is true for about every noun you can out there. “Premature design is the root of evil”, “Premature programming is the root of evil”, “Premature debugging is the root of evil”, etc.

Adding all implies there aren’t other things that are (in this context) roots of evil. I don’t think that’s true. As an example, one can spend excessive amounts of effort thinking about, or worrying about the ‘beauty’ of source code.

I suspect when Knuth first came up with this phrase, he didn't expect it to be taken as gospel.

The original biblical quote it riffs off is often, mostly, misquoted as: Money is the root of evil.

It actually is (give or take for translation) "For the love of money is a root of all kinds of evil."

Timothy 6:10

The love...

A root...

All kinds...

>A good programmer will not be lulled into complacency by such reasoning

And that's the crux of it. Donald neglected to understand that most programmers will takeaway "optimization is bad" and all the subtleties of his point will be lost.

Then we get things like electron (ducks for cover)

Donald was also writing at a time when all languages were close to the metal and optimization meant using various tricks (or writing critical portions in assembly) to improve performance.

>"when all languages were close to the metal"

That writing was 1974, Lisp had already existed.

And even caches. Though we called it "core", back then. Main memory was disk, tape, or drum, and cache misses caused page faults, if you were fortunate, or you had to roll in overlays yourself. Nowadays RAM is as inaccessible as disk was then, and you swap 64-byte pages, sometimes with network negotiations with remote (NUMA) cores, all in hardware.

> Then we get things like electron

We get electron because it's a batteries included (and remote and TV) cross platform GUI.

And has a huge talent pool, and acceptable performance for most users.