Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Does anyone have a list of 'donts' when optimizing?

by BUU (Prior)
on Apr 16, 2002 at 13:52 UTC ( #159482=perlquestion: print w/ replies, xml ) Need Help??
BUU has asked for the wisdom of the Perl Monks concerning the following question:

Mostly im asking if anyone has something like 'Top 5 functions to avoid when trying to write speedy code'.. If any function takes alot of resources or is really inefficient. Or hell, anything related to optimization, particularly in a cgi context, but in general as well.

Comment on Does anyone have a list of 'donts' when optimizing?
Re: Does anyone have a list of 'donts' when optimizing?
by Biker (Priest) on Apr 16, 2002 at 14:03 UTC

    Dont:

    while(1){}



    Everything went worng, just as foreseen.

      Not really hints on how to optimise, more hints on how to avoid a lot of problems with it. Make sure your code works beforehand, and use unit tests such as Test::More, or Test::Harness to make sure your code remains working whilst you're torturing it. Yes, there are rather a lot more of them to chose from if you look.. this is one wheel important enough that it's worth having a few choices as to what colour you want.

      Oh, and make sure you know the output from your profiler. There's nothing worse than optimising the wrong part.

      <CITE>"Premature optimization is the root of all evil." - Donald Knuth</CITE>

Re: Does anyone have a list of 'donts' when optimizing?
by talexb (Canon) on Apr 16, 2002 at 14:10 UTC
    Don't work on speeding stuff up that has little or no effect on the overall efficiency.

    Reminds me of the time I helped my friend move a clothes washer. I insisted that we remove the agitator first, and spent five minutes removing it to find -- surprise! it only weighed about a pound, and we still had to carry the rest of this 180 pound monster up a flight of stairs and onto a pickup.

    He was very patient. Never said a thing, but he sure smiled a bit.

    --t. alex

    "Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny

Re: Does anyone have a list of 'donts' when optimizing?
by wardk (Deacon) on Apr 16, 2002 at 14:18 UTC
    one "DO" comes immediately to mind as I have dealt with it recently with a system that went from reasonably few transactions (departmental) to high volume (enterprise wide usage).

    If using a database, create as few connections as possible. DB connections are expensive and in a high transaction CGI (as well as non-CGI) scenario, creating multiple connections where less (one is best) will do will have a significant impact on your response time, as well as anyone else you may be sharing db resources with (like listeners).

    Of course this suggestion (as well as many others you may receive on this) is really valid for all languages.

Re: Does anyone have a list of 'donts' when optimizing?
by Fletch (Chancellor) on Apr 16, 2002 at 14:53 UTC

    If you can at all manage it, don't run as a CGI. Use FastCGI or mod_perl. That'll immediately cut the overhead of each request by a large amount. And see the excelent mod_perl guide for mod_perl specific tips.

    If you must have real CGIs, fork off a child (or pass off the work to another persistent process) to finish any long running tasks after you've interacted with the browser. That'll let the httpd you're interacting with go on and service another request.

Re: Does anyone have a list of 'donts' when optimizing?
by simon.proctor (Vicar) on Apr 16, 2002 at 15:23 UTC
    Don't think theres always another optimisation you can apply.

    You'll end up wasting time shaving that extra microsecond off when you could be focusing on a better solution, an n-tier application for example.

    Update: fixed my bad English :). Guess I'm too tired.
Re: Does anyone have a list of 'donts' when optimizing?
by thelenm (Vicar) on Apr 16, 2002 at 15:39 UTC
    My favorite quote about optimization:

    Rules of Optimization:
    Rule 1: Don't do it.
    Rule 2 (for experts only): Don't do it yet.
    - M.A. Jackson

    And some others I blatantly stole from the Java Optimization page:

    "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."
    - W.A. Wulf

    "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
    - Donald Knuth

    "The best is the enemy of the good."
    - Voltaire

Re: Does anyone have a list of 'donts' when optimizing?
by dws (Chancellor) on Apr 16, 2002 at 15:47 UTC
    Mostly im asking if anyone has something like 'Top 5 functions to avoid when trying to write speedy code'

    Avoid   sleep()
    Seriously, though, my answer is:

    "Don't worry about speed before it's clear that a) speed is important, and b) speed is a problem, and c) the problem is one you can get at."

    I've seen too much time go down the drain in projects when somebody decides to rework some chunk of the system to be as fast as possible, when it really didn't matter. The result is usually code that's problematic (less readable, less supportable) than if they'd just been straightforward.

    Performance problems are almost always algorithmic (where "algorithm" includes the structure of SQL queries).

Re: Does anyone have a list of 'donts' when optimizing?
by tachyon (Chancellor) on Apr 16, 2002 at 18:54 UTC

    To optimise you need to identify where the time is spent. The most useful tool is Devel::DProf which will detail the percentage of time spent in each section of your code. You are wasting your time doubling the speed of a part of code that only takes up 1% of the total runtime. On the other hand a small improvement in bottleneck areas will reap large benefits. Assuming you have a 'normal' database driven website consider:

    1. Profiling with tools, see Devel::Dprof is your friend
    2. Optimising bottlenecks with Benchmark et al
    3. use mod_perl and Apache::Registry or for vanilla CGI CGI::Simple or CGI.pm in order of speed to process your params.
    4. Generate a cache of static documents for slow changing content rather than serving all requests from a database
    5. Connect to your database once (slow) and use prepare_cached($sql) with ? placeholders in the SQL and then execute(@values)
    6. Think about how much your time is worth versus the cost of new faster equipment or more ram or more processors or faster disks or a better load balancer or....

    Often perlcode per say is not the bottleneck. You can't effectively optimise unless you identify where it is worth investing the effort.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Re: Does anyone have a list of 'donts' when optimizing?
by danichka (Hermit) on Apr 16, 2002 at 19:38 UTC
    Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught.
    --Larry Wall

    My list of don'ts is pretty short. Don't get caught! :)


    use Your::Head;
Re: Does anyone have a list of 'donts' when optimizing?
by BUU (Prior) on Apr 16, 2002 at 21:31 UTC
    Much thankx for all the interesting replies, im off to go play with devel::dbprof right now. Just fyi, im not really working on a company project type thing, just some code ive been playing around with, and getting it to go as fast as i can is kind of a hobby.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (11)
As of 2014-12-17 20:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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





    Results (32 votes), past polls