note FoxtrotUniform <p>My usual procedure for optimizing something is:</p> <ol> <li>Profile it, to find out which part of the problem is taking the most time. (Sometimes the problem's a single algorithm, in which case this isn't really necessary.) </li> <li>Estimate the asymptotic bound of that bit of the problem. (Yet another excellent real-world use for those icky awful theory courses you were forced to take in university. :-)</li> <li>Try to make the algorithm faster. Sometimes this just isn't possible; IIRC, you can't get a general sort on a single-processor machine faster than O(n log n). But you can often simplify the problem: put a few restrictions on what you sort, and you can get down to O(n). Nobody knows how to solve the travelling salesman problem in less than exponential time, but if you don't need a perfect solution, just one no worse than twice as bad as optimal, you can do it in polynomial (cubic, IIRC) time.</li> <li>Repeat until you run out of relevant sub-problems.</li> <li>If it still isn't fast enough, profile it again; this time, look for lines and functions that get executed most often, and try to slim those down. If your program's data set is particularly small, this might be more important than step 2; then again, if n is small, your program's probably "fast enough".</li> </ol> <tt>-- <br> :wq</tt> 135852 136073