Jaspersan has asked for the wisdom of the Perl Monks concerning the following question:

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re: Performance
by robobunny (Friar) on Jun 24, 2002 at 15:45 UTC
    one sure way to make any script run faster is to use the "Fast Access Kernel Environment" character at the beginning of the line. by adding a simple # to the beginning of every line of your script, you can increase performance by 100 fold easily!
      rofl, i do know that # is a comment :P.

      My code is here:
      http://www.wintermarket.org/~jasper/shitz/files/decyphile22b.zip. Im not sure if thats the updated one :\, but it still is causing problems.

      Thanks
      ^jasper <jasper@wintermarket.org>
Re: Performance
by FoxtrotUniform (Prior) on Jun 24, 2002 at 15:52 UTC

    The first thing you want to do is profile your script. Use Devel::DProf and/or Devel::SmallProf to find out which parts of the script are taking the most time: optimize those first. (It turns out that most programmers have horrible intuition about which parts of the code are taking the most time, so profile instead of guessing.)

    Once you have a list of hot-spots, optimize them. The best way to speed up code is to use a faster algorithm, especially for large data sets. Have a look around google for better algorithms. (On small data sets, it's sometimes best to use a simpler, "slower" algorithm: the faster ones tend to have high setup costs, and are only faster in the long run.) Failing that, there are lower-level optimizations that can be done: iterating over a list with foreach rather than indexing into it inside a C-style for loop, for example. (Programming Perl has a section on code optimization.)

    If you've tried all that, and your code's still too slow, you might be able to post some of it here, tell us what you've tried, and get further advice.

    Two non-Perl solutions: if time is more important than money, you should consider buying faster hardware. (If your process is using lots of memory and swapping, even $50 worth of RAM could make a huge difference if it cuts way down on disk accesses.) It might also be worth it to re-write your program in a faster language (C is the canonical example, but I've had good luck with compiled Haskell lately), especially if it's doing a lot of number crunching.

    --
    The hell with paco, vote for Erudil!
    :wq

Re: Performance
by dws (Chancellor) on Jun 24, 2002 at 20:29 UTC
    I have a script that is using too much cpu cycles, i was wondering how i can fix this, and maybe speed up the script a bit.

    Here's the basic five step plan for dealing with Performance issues:

    1. Find out where your script is spending most of its time (via profiling, putting in code to record timestamps, whatever). Go there.
    2. Look for work that you don't need to do, and don't do it.
    3. Look for work that only needs to be done once, rather than over and over and over. Do that work once.
    4. Look for less (time) expensive ways of doing whatever work is left over.
    5. Repeat steps 1-4 until performance is good enough.

    Conceptually, that's it.

Re: Performance
by davis (Vicar) on Jun 24, 2002 at 15:43 UTC
    If you show us some code, we might be able to pick out some slow bits, otherwise it'll be pretty difficult for us to remotely optimize programs we've never seen.

    On a (possibly) more helpful note, you might want to look at Devel::Profile, which is able to tell you where the most time is being spent, thereby allowing you to direct your optimization efforts on the problematic areas.

    cheers
    davis
    Is this going out live?
    No, Homer, very few cartoons are broadcast live - it's a terrible strain on the animator's wrist

Re: Performance
by neilwatson (Priest) on Jun 24, 2002 at 15:39 UTC
Re: Performance
by grinder (Bishop) on Jun 24, 2002 at 16:53 UTC

    Buy a faster computer.