4 ms·
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 harde
by dilap 4y ago
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.)
- 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.
- civilized 4y agoSurely 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".
- Ygg2 4y ago> 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.