begin quoting Gabriel Sechan as of Wed, Aug 23, 2006 at 12:47:44PM -0500: > >From: "John H. Robinson, IV" <[EMAIL PROTECTED]> [snip] > Depends on the level of optimization. If you're dropping into assembly or > rewriting an entire portion based on implementation details of another part > of the code, its probably a bad idea.
With proper encapsulation, you shouldn't care about the implementation details of another part of the code. In theory. :) > Taking a minute to think about what > you're doing and realising that calling function Foo can be done outside of > a loop is a good idea. "Taking a minute to think" is great advice. "But taking half a day to *measure*" is better advice. Ideally, you want to do both. And remember to measure both before and after you make a change. [snip] > >Your profiler will show you where the bottlenecks are. You won't know > >that until it actually works. You can guess, but you will likely guess > >wrong. > > I disagree on likely guessing wrong. In my experience you generally guess > most of the top 10, but 1 or 2 surprises may come. My experience has been otherwise -- programmers who brag about their ability generally miss most of the top 10, and may get 1 or 2 of the obvious bottlenecks right. The consensus seems to be that programmers are, in general, *terrible* at predicting bottlenecks. > I'm not syaing drop to assembly, or throw out encapsulation or legibility > to improve performance. I'm saying think about performance when you code > and design. And we're not saying that one should seek out the slowest possible algorithms. But if it comes down to making a decision between performance and managing complexity, choose to manage complexity over performance until AFTER a profiler has gotten involved. > The modern "well Murphys law will save us" cult is going to be > in for a big surprise with processor speeds begining to flatline. Murphy's law never saves us. :) Moore's law, on the other hand... well, we'll see. But then, I'm bitter -- the market chose x86 IBM-compatibles, so let 'em suffer. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
