From: John Carter <john.carter@...>
Date: 2006-05-24T07:10:25+09:00
Subject: How use Profiling, a Quick Guide.

On Tue, 23 May 2006, Mark Somerville wrote:

> Can anyone recommend some good or tutorials on profiling and benchmarking?
> Although I have used them both (from the standard library), I feel I lack
> fundamental knowledge about how to go about it.

I don't know of any Good one but here are some things I do...

  * Always benchmark first, profile and optimize later. Otherwise you don't
    know whether it was worth it. (Hint: Often the tweaks aren't worth it, or
    make things worse)

  * Look at the top most items in the profile list. Usually they are
    standard library functions. Silly things like [] or +...
    Ask your self, "What could be calling these thing so often?
    Can I make it do it less often? eg. Cache the result etc.)

  * Scan down the list for the first few user written methods. Usually the one
    that you spent the most time in has the most fat to trim.

  * Scan the list for the routine that took the longest (as opposed
    to the most time spent in it.) Try get that one to just do less.

  * Use strace, see what the system is doing at an OS level. I once
    improved another persons program (professional in production) by a
    factor of 40, yes FORTY times, by noting it was doing an lseek on every
    record read and changing that to an mmap.

  * Always look out for surprises. The best moment in an optimizers life is
    when you look at something and say "WTF! Why is _that_ routine taking so
    long!?"

  * Large number of calls to .size and .length and .count_objects methods are a
    clue some nidjit somewhere is doing something really N^2 stupid like...
     for( i=0; i < container.count_objects(); i++) {
     }

  * Use top, vmstat, times as well.
     Large usertime means optimize program.
     Large system time means you really hammering the system calls (that
     was a clue in the lseek case I mentioned above)
     Large real time small user and system means you are waiting for
     input from user / disk / network /...? Find out what.
     Watch the page in page out stats. Watch the swap in swap out stats.
     If you are paging or swapping, time to switch to memory consumption
     optimization!

   * Use my memprofile /  newprofile tricks to try spot the
     http://wiki.rubygarden.org/Ruby/page/show/NewProfiler
     http://rubyforge.org/snippet/detail.php?type=snippet&id=70


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.