Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

(tye)Re: Premature optimization

by tye (Cardinal)
on Jan 04, 2002 at 00:41 UTC ( #136073=note: print w/ replies, xml ) Need Help??


in reply to Premature optimization

I hear lots of "speed" talk here and it is almost always premature nano-optimization. You describe problems with premature optimization. I think the nano-optimization and micro-optimization is perhaps a worse problem for many Perl programmers.

I marvel at people (including me, sometimes) running benchmarks to estimate how much faster single quotes are to double quotes, whether for is faster before a loop or after a statement, whether && is faster than and, whether arrays are faster than hashes, whether globals are faster than references, etc.

The most common conclusion is that X is 20% faster than Y (seriously). And that usually means your script can be changed from taking 1.2 seconds to run to an impressive 1.1999 seconds to run!

If a script is running "too slow", then optimizing simple things is very unlikely to make it run "fast enough". On rare occasions, you'll find a fairly simple thing that is getting done many thousands of times such that making it significantly faster will make your while program only moderately faster.

But don't assume you have such a rare case unless you have some decent evidence. That is what things like Devel::Dprof are meant to help you figure out. So work on figuring out what the bottleneck is before you spend effort trying to remove it.

But, if a script is running "too slow", then your only reasonable hope for fixing that is to make changes to the global structure, to the algorithm. Instead of making one operation 20% faster, make it so you process/store the data in a different format/order so that you can find what you want with one operation instead with 10,000, for example.

        - tye (but my friends call me "Tye")


Comment on (tye)Re: Premature optimization
Download Code
Re(2): Premature optimization
by FoxtrotUniform (Prior) on Jan 04, 2002 at 01:38 UTC

    My usual procedure for optimizing something is:

    1. 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.)
    2. 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. :-)
    3. 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.
    4. Repeat until you run out of relevant sub-problems.
    5. 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".
    --
    :wq

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://136073]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (10)
As of 2014-12-27 04:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls