If I read this one more time, I will puke ...
Yesterday, I read yet another person quote Knuth saying, "Premature optimization is root of all evil". Knuth wrote that in 1974 in the era of punch cards. Over the years, I've seen this statement used to defend bloatware, slugware and complexware. I'm tired of it.
Of course, when you are prototyping, don't be concerned with performance because you are prototyping. At the same time, if there is something simple you can do to be faster, do it! That way nobody has to come back later and optimize your code.
Steve
Of course, when you are prototyping, don't be concerned with performance because you are prototyping. At the same time, if there is something simple you can do to be faster, do it! That way nobody has to come back later and optimize your code.
Steve
posted by Steve at
11:27 PM
6 Comments:
Premature optimization is the root of all evil.
I'll send over a bucket and some rags.
FWIW, I'm more of a fan of "run, right, fast, small".
By
Wayne, at 6:56 AM
I think another interpretation is: don't optimize before you understand the problem completely. My first pass through any project is usually a learning exercise...
Todd Chambery
By
Felonious Ham, at 7:56 AM
Agree,
Premature optimization ends in rewrite :(
By
Nirav Thaker, at 7:59 AM
The argument still holds today; it's just YAGNI rather than bleeding edge of hardware. After all, most computation isn't on the critical path of any app, so unless you happen to hit the part that is on the critical path an optimisation isn't going to make any measurable difference overall.
There might be valid differences if you're writing an API which is going to sit on the path all the time, but that's an exceptional case rather than the rule. In any case, unless you've profiled how people are using the library, it might be that you can't know what to optimise efficiently.
After all, microbenchmarks (and optimisations for them) don't actually tend to show real world performance.
Lastly, there's also the code understanding part. If you're the only person that needs to understand something, then less of an issue, but if someone in the future is coming across and picking up your work, it helps to have legible code. Let tools like LLVM or GCC or JIT take care of the optimisations, and just write good code.
(PS It's much more important to understand the difference between an O(n) and O(log n) algorithm and knowing which one to pick than generic optimisations)
By
AlBlue, at 8:47 AM
The problem is that people are stuck with an application that is a "little bit slow" everywhere.
Remember I said that if you can do something simple to be faster, you should. I didn't say "rigorously optimize your prototype".
Al, I agree that algorithms are the most important thing.
... and finally, everything ends in rewrite as soon as the original engineer leaves!
Steve
By
Steve, at 9:36 AM
Hi Steve,
I completely agree with you.
There are always simple things that can be done in the right way (performance wise) in the first place. Finding those kind of problems later on can be time consuming.
Furthermore there are things that often cannot be easily fixed afterwards.
Not taking care of how many network round trips you do is an example that comes to my mind. Network latency is something that will not be improved by better hardware any time soon.
Regards,
Markus (https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/6389)
By
Unknown, at 4:56 AM
Post a Comment
<< Home