6 ms·
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 tec
by dilyevsky 4y ago
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
- Jtsummers 4y agoWhy 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.)
- dilyevsky 4y agoIt’s just an expression ofc i blame the engineers (actually mostly tech leads and management)
- dilap 4y agoI 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.)
- pxmpxm 4y ago>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.
- bluGill 4y agoThe 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
- andrekandre 4y ago> 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)
- Gibbon1 4y agoLatency, power consumption, and safety have the problem that if they aren't a first order requirement they're expensive/impossible to bolt on after.
- pxmpxm 4y agoReminiscent of the "simplify and then add lightness" quote from Colin Chapman (of Lotus cars fame)
- Gibbon1 4y agoYeah 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.
- pessimizer 4y agoNobody is blaming the quote, a quote is ink on paper. People are blaming the programmers and management who cite the quote in their reasoning.
- pxmpxm 4y agoVirtually 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"
- aliqot 4y agoA 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.
- happytoexplain 4y agoIt'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).
- userbinator 4y agoSX/SO are full of such anti-intellectual cargo-culting. I've avoided them for anything but the shortest of answers.
- sly010 4y ago""premature optimization is the root of all evil" is the root of all evil."
- elteto 4y agoShould be: Premature “premature optimization is the root of all evil” is the root of all evil.
- happytoexplain 4y agoYup. 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.
- attractivechaos 4y agoWell, 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.
- ncmncm 4y agoI don't encounter mention of "the hot path" anywhere near often enough. Defend Your Hot Path!
- mastax 4y agoI 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.
- userbinator 4y agoIMHO 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.
- sicariusnoctis 4y agoNew quote just dropped: Premature complexity is the root of all evil.
- IshKebab 4y agoMaybe 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.
- kaba0 4y agoOr extended with the context, like “Yet we should not pass up our opportunities in that critical [hot loop]”
- intelVISA 4y agoIt'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.
- RunSet 4y agoFor 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.
- phendrenad2 4y agoWell it's the art of computer programming, not the art of shipping performant software. People just need a more rounded education.
- mmis1000 4y agoYep, 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.
- ww520 4y agoAlso 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.
- andrekandre 4y ago> 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...
- userbinator 4y agoIt's ironic when the end users of the software are themselves developers. "Reap what you sow."
- spaetzleesser 4y agoThe funny part is that often interviewing is about knowing algorithms. But then it's frowned upon if you actually implement one.
- gfaster 4y ago"Dammit, I went to school for the whole algorithm, I'm gonna implement the whole algorithm!"
- tuyiown 4y agoWhile 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.
- loup-vaillant 4y ago"Don't roll your own… anything"
- moralestapia 4y agoAnother 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.
- adammarples 4y agoAnd how is that being abused and misunderstood there?
- idiocrat 4y agoNobody 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.
- eru 4y agoAs far as I can tell, it's quite common to do work to improve the performance of existing systems?
- nurbl 4y agoProbably, 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.
- kaba0 4y agoThough it does ultimately boil down to no “fearless” refactoring being possible in real life. Unfortunately we seldom have such systems and test coverage/quality.
- 2OEH8eoCRo0 4y agoThe quote implies optimization at a later date.