4 ms·
When in doubt, I've usually found it faster to just write the optimized version and never measure.
by SamReidHughes 8y ago
When in doubt, I've usually found it faster to just write the optimized version and never measure.
- lolc 8y agoThat's a recipe for convoluted code with no benefit. It's what we call premature optimization.
- SamReidHughes 8y agoNo, it's called saving effort, because the situation requires determining whether the optimization is worth it anyway. Convoluted architecture is a problem, not some code that's an O(1) rewrite away from being simplified.
- lolc 8y agoI think your definition is off: Optimized does not mean simplified. Optimized code tends to be harder to understand for the reader. And readability is the first metric any code is judged by. If you want to optimize away from the plain version you have to support the introduced loss in legibility with relevant measurements.
- SamReidHughes 8y ago> Optimized does not mean simplified. I didn't say that and was assuming the opposite, so I think you've misread me. Obviously if the faster version is substantially more complicated it's a downside.
- lolc 8y ago"Optimized code" has an established meaning in our field. It's beyond simplified. Don't tell me I'm misreading you when I make you aware of the distinction. I've understood what you wanted to say, albeit with difficulty. Just say "Ah, I meant simplified."
- SamReidHughes 8y agoI never meant simplified by optimized. Simplification is what you do (with O(1) effort) when removing the optimization. When they are the same thing, there is no trade-off to be made.
- ColinWright 8y agoI've found situations where the code that everyone thought would be faster was, in fact, slower. Your assertion of "just write the optimized version" assumes that you always know which version would be faster - I'd suggest that there will be times when you are wrong, and you won't always know which times they'll be.
- SamReidHughes 8y agoIf you don't have the time budget for that, you have to make the trade off of probabilities. It's perfectly possible to hold a basic model of the CPU in your head and predict the performance of your code. The whole reason why people tell you to hold a model of CPU and memory latencies in your head is so that you can avoid writing the slow version in the first place.
- mhh__ 8y agoA famous quote by Knuth comes to mind... Fast code is often unreadable or unmaintainable, software should be written with it's lifespan in mind. That's not an invitation to write slow code, but microoptimizations can be a disatrous temptation (Especially when writing low level code). Compilers are pretty fucking good these days so I think trusting them can be very helpful. How can you know if you don't measure?
- SamReidHughes 8y agoI know what compilers do and might not do to code, so they're not the issue. I'm not talking about a x ^= y ^= z here, I'm taking about alternate algorithms and data representations.
- detaro 8y agoIn how many cases are you certain that the "optimized version" is actually better without measuring? People tend to carry a lot of ideas about what should be faster that don't necessarily hold in practice.
- SamReidHughes 8y agoIn tons of cases you are in fact "certain." You don't need an experiment to know that pointer chasing is going to be slower than array iteration, or that in some circumstance pulling a function out of a loop might be better but won't be substantially worse than the compiler's output. Generally speaking, the cases where you are unsure, it's sensitive to platform details or unstable compiler optimizations, or you don't know what sort of user input you'll really get. Or in the case of the blog post, if you don't have a good model of the execution environment in your head (because Python).
- detaro 8y agoOk, fair to your examples, I for some reason wasn't thinking about high-ish level decisions like that (and some annoying memories of people writing "optimized" code that was hard to read and not any faster than what the compiler did with the simple one)