Hacker News Reader

Comment by dilyevsky | Hacker News Reader

I personally blame the “premature optimization is root of all evil” quote which most of the time is taken out of context but formed a lasting impact in many tech leaders’ minds

View on HN

I was writing an NMEA parser today. (NMEA 0183 is a common serial GPS data protocol) My serial port reads returned an IOvec-like type which exposed limited operations. I spent probably an hour making helper functions and doing various verification and parsing operations on the IOvec type because it saved having to copy the data into a contiguous buffer. Midway through I stopped and realized that I would only need to copy when the ~50B message straddled the end of the ~64kB buffer. It takes a few nanoseconds to copy 50B. I spent an hour on an optimization that would never do anything but complicate the code. If I had just written the simple and obvious code, and spent that hour profiling the application to optimize what would actually make a difference, I'd be much better off.

That is what the quote is talking about. I don't think you can blame the quote if people are just ignoring the first word, and I'm not convinced that's actually a common thing.

IMHO that's better called "premature complexity".

You shouldn't even need to profile to realise that if you're using a serial port for I/O, unless your hardware is something embedded and in the low-MHz, range, you'll spend most of your time waiting for I/O unless you massively overcomplicate your solution.

New quote just dropped:

Premature complexity is the root of all evil.

Maybe you can't blame the quote author but the quote itself is definitely a problem now.

In my experience it is mostly used as an excuse not to think about performance at all. "The quote says we can worry about it later!"

That's why the quote needs to die.

Or extended with the context, like “Yet we should not pass up our opportunities in that critical [hot loop]”

The "hot loop" is also a myth. Very few programs actually have a hot loop with larger-than-average returns on optimizations. Heck, the blog post itself is an example of that not being the case - it's startup that's slow, not the program's steady state hot loop. For something you actually spend a significant amount of time using continuously, yeah maybe it has a hot loop. But even then, probably more like hundreds or thousands of hot loops depending on the features being used, what stage the program is in (eg, blender while editing the scene is very very different from blender while exporting a rendering).

In other words: first, understand your data.

That's what Mike Acton says before he shakes your hand in the morning.

Virtually every single performance thread on stack exchange has that one guy that says regurgitates something about premature optimizations and maintainability eg

Q "I'm working on high throughput data science thing, is branchless math better than conditional instructions here, because this thing needs to take less than a lifetime to finish"

A "You should focus on code readability, it's way more important ..yadeyadaya ... i work on python and websites"

I blame slipping standards in CS programs and the entire concept of "information science"

A good mentor told me once not to let 'perfect' be the enemy of 'good'. At the time I thought it was clever but it didn't really hit home until year 10 or 15. I did a lot of things that made no difference to the user, but to me was finesse.

It's definitely a good thing to keep in mind. Perfectionism is a real danger. However, do note that there are entire categories of code quality worth keeping up that make no difference to users now. A simple example would be maintainability (whatever that means in each case).

SX/SO are full of such anti-intellectual cargo-culting. I've avoided them for anything but the shortest of answers.

> SX/SO

I've tried googling this, and I can't figure out what you're talking about.

StackExchange StackOverflow

StackExchange/StackOverflow

Is he the same guy as the one who keeps repeating that nowadays java is actually faster than C++?

The hell of it is, there is plenty of Java that really is faster than plenty of C++. You can make C++ go as slow as you like.

Tbh, most performance questions I see on SE are bad too. The necessary question here is: what's the profile of the whole thing - does this line of math even matter? The questions that are already researched to the level where the original question makes sense are extremely rare - and I do enjoy those.

Also the "developer's time is expensive" belief pushes developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with the goal of application, but hey, it's cheaper to just slap something on the existing packages and ship it. The "expensive parts" are pushed to the end users.

It's ironic when the end users of the software are themselves developers. "Reap what you sow."

The funny part is that often interviewing is about knowing algorithms. But then it's frowned upon if you actually implement one.

While you are right to an extent, I'd rather have someone that can check if the implementation is correct for the use case, wether it's theirs or someone's else, and settles for someone's in first when it fits.

"Don't roll your own… anything"

"Dammit, I went to school for the whole algorithm, I'm gonna implement the whole algorithm!"

Adding on to that, “QA time is expensive” too. I’ve learned from experience that trying to tweak well established repos/libraries rarely gets management’s approval because the extra time it would take to QA and regression test is considered pure loss. Better to leave it be and force the new code to work with the old stuff. That way it is at least billable.

> Also the "developer's time is expensive"

Agreed. I really dislike this excuse for sloppy slow code.

Yes, developer time is expensive, need to keep ROI in mind.

But if the expensive developer spents a week optimizing the function to make it 1 second faster, is that worth it? Too many people will respond "developer's time is expensive" without thinking beyond that. But of course, it depends.

If that function is being invoked millions of times per day by hundreds of thousands of people, it very quickly becomes totally worth it.

I don’t know, should I really reimplement that graph lib in a buggier, slower way, over choosing a battle-tested one that may also contain some additional features I don’t need?

According to Brook’s famous paper, code reuse is the only way to significantly improve programmer productivity. No new language will suddenly make you 10x faster, and even that would be meaningless against all the quality code bases out there.

  > developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with the goal of application, but hey, it's cheaper to just slap something on the existing packages

and in many cases those layers and layers actually slow development long-term because of that mis-alignment and needing to untangle/manage the mess of dependencies over time...

Yup. There surely is such thing as over-optimized, early-optimized, over-clever, over-terse, over-engineered, over-abstracted, etc. But in terms of actual impact in the software ecosystem, the simple problem of not-good-at-programming still blows them all out of the water, combined.

It's important to be able to recognize which of the two echelons of problem-space one's codebase inhabits.

"over-engineered" and "over-abstracted" don't belong with the others. They are extremely common in slow software, which is most software.

I would say that over engineered is not-good-at-programming. Though it's a mistake made by more experienced developers.

It's a great maxim but it's misapplied.

What's ironic is premature optimization is not just code, using K8s or expensive cloud solutions when a bare metal dedi will suffice. etc.

Instead it's just parroted by people who want to churn out MVP quality code in prod.

For many readers that quote is the only part of The Art of Computer Programming they can comprehend. No wonder they bikeshed it to hell and back.

Well it's the art of computer programming, not the art of shipping performant software. People just need a more rounded education.

Well, modern programmers more often think "optimization is the root of all evil". I read an article that literally recommends not to optimize until the end.

I don't encounter mention of "the hot path" anywhere near often enough.

Defend Your Hot Path!

Nobody wants to do post-mature optimizations, as in never touch a running system.

No one will say thank you for fixing something, but everybody will blame you if you fail trying.

As far as I can tell, it's quite common to do work to improve the performance of existing systems?

Probably, but it is a good point: premature optimization is easy and fun because you're doing it while writing the code and it's already in your head. Optimizing a large, working, congealed codebase that you didn't write is often hard and feels risky, even with good test coverage. Very local optimizations, fine, but those requiring refactoring? Less likely to happen.

Maybe there's a golden opportunity somewhere inbetween where optimization is not premature but also not painful to do.

Though it does ultimately boil down to no “fearless” refactoring being possible in real life. Unfortunately we seldom have such systems and test coverage/quality.

""premature optimization is the root of all evil" is the root of all evil."

Should be:

Premature “premature optimization is the root of all evil” is the root of all evil.

Yep, I think baseline optimize should be just build into the core of framework or language. Specified optimization could be applied later but not these. Basic caches that don't affect performance or memory should just be enabled by default instead of some "let's just don't optimize it at all until it lags like hell" shit like react.(Spoiler: nobody actually optimize it in the end) I hate websites written by react so much because of this.

Another one that's been abused and thoroughly misunderstood is "correlation does not mean causation".

You could come up with data showing an R^2 of like 0.99 and there's always a smartass that immediately parrots "but remember that correlation does not mean causation". Ugh.

And how is that being abused and misunderstood there?

The quote implies optimization at a later date.

Why blame a quote, an inanimate thing, and not the foolish programmer that scans the entire `Documents` directory just to ignore most of it and only keep the results of the `Sound Recordings` subdirectory? (Among other apparent issues with this program.)

It’s just an expression ofc i blame the engineers (actually mostly tech leads and management)

I think that quote can often be the source of misguided beliefs like "it's OK to scan the whole Documents directory".

'Cuz why waste time doing something harder? Premature optimization and all that.

Honestly, in my experience, basically the opposite of the quote is true. If you want your software to be fast, you need to be thinking about speed in the design from the very beginning. Very hard, perhaps impossible, to make something not designed for speed from the beginning be as fast as something that was.

Of course there's a difference between having a holistic design that you know can go fast and immediately wasting time eeking out x% of speed in some random sub-fn that will only run y% of the time, when x and y are small.

But really performance does need to be built into the design.

(As an example, look at the heroic steps that are being taken to try to make the Rust compiler faster. It's slowly getting better, but it will never be fast. On the other hand, I would predict that if you started making a Rust-like-language from day 0 with a fast compiler as a goal, you could get something much faster.)

>If you want your software to be fast, you need to be thinking about speed in the design from the very beginning. Very hard, perhaps impossible, to make something not designed for speed from the beginning be as fast as something that was.

This is absolutely true in low latency finance.

The quote is talking about micro optimization, but people think they should apply it st design time. That is wrong, the right data structures up front make mmicro optimizations mostly unnecessary (assuming a modern optimizing compiler) while if you get that wrong nothing will fix performance but a major rewrite

  > the right data structures

maybe a little pedantic, but i would just add that ensuring those all work together well is an important aspect that is often overlooked (one data structure in isolation may be "fast" but slower overall etc)

Latency, power consumption, and safety have the problem that if they aren't a first order requirement they're expensive/impossible to bolt on after.

Reminiscent of the "simplify and then add lightness" quote from Colin Chapman (of Lotus cars fame)

Yeah one should consider whether a choice bakes in something against the ultimate requirements or is just a trivially replaceable stop gap. Bonus sometimes you find the stop gap is actually acceptable.

Surely no one thinks that "when searching a directory, specify the full path of the directory you want to search" is premature optimization...?

Isn't that just... doing the thing you intended to do, in the most straightforward way possible?

Who says "it's too much trouble getting the files in the directory I want, I'd rather search the entire computer and filter that list down to the files in that directory"?

This is like saying "it's too much effort to drive to San Francisco, so I'm going to drive to cities in California until I happen to arrive in San Francisco".

> As an example, look at the heroic steps that are being taken to try to make the Rust compiler faster. It's slowly getting better, but it will never be fast.

Eh. It's fast enough. And anything with overhead of borrow checker and focus on runtime performing, wouldn't be fast to compile either.

Biggest win could be getting rid of LLVM but that would have crippled its development speed.

Nobody is blaming the quote, a quote is ink on paper. People are blaming the programmers and management who cite the quote in their reasoning.

Reply on news.ycombinator.com