Hot Diggety! Brad Knowles was rumored to have written: > on 5/27/09 12:37 PM, Robert Brockway said: > > > Performance analysis can get very indepth. Once you resolve one > > bottleneck another will appear but fixing them becomes a case of > > diminishing returns. > > Here's one rule I've learned -- the higher up in the layers you can make > an optimization, the more you're likely to save. > > Fixing a problem in the application source code is likely to give you > a lot more bang for your buck than trying to apply an optimization at > a lower layer that lets you try to deal with the effluent coming out > of the app.
Indeed. That's along the lines of one of Professor Knuth's major points made, with respect to choice of algorithms used. Somewhere in the mists of time, we once had a perl-based tool that took 20 minutes for a complete run. After some investigation, utilizing perl's Devel::DProf, analysis of DProf results, and some careful thought about the code... We eventually realized it was because the app was accessing the array in a *very* inefficient way that was much closer to O(n^2) than O(n). Not readily noticeable when the data set is small, but majorly so when it's large, obviously. >From what I vaguely recall, merely inverting the data structure access brought the total runtime down to about 15 seconds or so. Far fewer really expensive CPU cache misses that way. And also, when in doubt, don't try to over-optimize the idle loop. ;-) (Sorry; couldn't resist! Suitably chastened, I now return to my lair.) -Dan _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
