begin quoting Gabriel Sechan as of Wed, Aug 23, 2006 at 03:55:21AM -0500: > >From: Stewart Stremler <[EMAIL PROTECTED]> [snip] > >I like his favorite line: > > > > It is easier to optimize correct code than to correct optimized code. > > [snip] > > Given that his website refuses to load, I think he should have cared about > its performance a great deal more :)
Funny, it works for me. :) > Here's the problem with the idea of optimization at the end. CHanging the > code later is more expensive than changing it early. Its cheaper to fix a > bug in design than in coding, its cheaper to fix it in coding than in > testing. Yes. > The same is true for optimization- I disagree. > a little time spent worrying > about performance early will make it a lot cheaper to achieve it than it > would be later on. But software development people almost always guess wrong as to where the true bottlenecks will be. A little time worrying about modularity and clear interfaces early will make it easier to optimize later on, but actually trying to predict the bottlenecks? That's not "a little time", that's a _lot_ of time and effort. > By the time you get to the end and try to optimize, you > end up spending large amounts of time trying to figure out what to > optimize, then an additional large amount of time doing so. And throwing > out time already spent on the unoptimal solution. Whereas considering You don't spend large amounts of time trying to figure out what to optimize ... you use a profiler. It will _tell_ you what to optimize. That's what it does. People shouldn't have to do the tedious and boring work, they should let the computer do it. The time spent on the "unoptimal" solution lets you get your regression tests written against something you have some confidence in being able to fix if it turns out you have a bug. > performance in the planning stage requires no rework or wasted time, and > doing so in the coding stage requires much less (you're already in the > mindset and familiar witht he area of code). Yeah, you'll miss a > bottleneck or 2 just like you'll miss a bug or 2, but the end result is > still a cheaper, better product than leaving it to the end. Again, I disagree. If you don't have a profiler, can't get a profiler, and have no way to profile your code... then maybe. If you're working on embedded systems with tight realtime constraints, and every instruction must have its execution time considered, perhaps. If you're at that level of coding, you've already got a chart that indicates how much time your program is spending in each section of code. Otherwise... use a profiler. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
