On Tue, 23 May 2006, Mark S. 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 C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
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.