Re: [Monotone-devel] Performance accounting and testing patch

[Eric Anderson]

Matthew Gregan writes:
 > At 2005-08-09T18:38:10-0700, Eric Anderson wrote:
 > > Summary: The attached patch adds in memory usage, copys and malloc
 > > accounting to monotone, and a repeatable performance test for
 > > evaulating CPU usage, memory usage, copies, and mallocs. Sample output
 > > is shown at the bottom after the detailed discussion.
 > 
 > Thanks, it's useful to have people looking at monotone's current
 > performance in a constructive fashion.
 > 
 > I don't think that the specific performance accounting code in the patch
 > needs to be included in monotone proper.  I'm not sure if you're
 > proposing that it should be, or if you're just making the patch
 > available for others who want to look at this aspect of monotone's
 > performance.

I'm proposing that some amount of performance accounting be added to
the monotone source code so that other people when they make changes
that are intended to improve performance, can verify that performance
has improved.  Also after a major change developers can verify that
the performance hasn't degraded.

 > To extract the same sort of statistics that you're recording right now
 > without requiring a patch on top of monotone, I'd look at putting your
 > stats collection code into a interposable shared library using the usual
 > RTLD_NEXT/LD_PRELOAD tricks.  The /proc/<pid>/statm part of the patch
 > could be move into a thin 'launcher' tool that would behave in much the
 > same way that /usr/bin/time works now.

This is a fine alternative I'll look into these possibilities.

 > If you want to look at monotone's heap usage in more depth, take a look
 > at Valgrind (specifically massif, the heap profiler).  It will allow you
 > to record and examine the call-stacks of the worst offenders.  For
 > general profiling, a recent version of oprofile with a recent 2.6 Linux
 > kernel is a good start.

I want something that is pretty fast because often when you are
debugging performance problems things are already slow.  Valgrind
usually slows things down by quite a bit and uses a lot more memory --
at least in the times I've used it before, has it gotten better to the
point where a 800 MB RSS size can be handled?

I tried oprofile on 2.6, but found that it didn't give me the
information that I wanted, gprof seemed to provide cleaner
information.

 > (Minor nit pick: the two files you added should go in scripts/, not
 > tests/.  The latter is the domain of autotest scriptlets.)

I don't have a scripts directory; did you mean contrib?  The perf-test
script seemed like a test, so tests/ seemed a better choice than
contrib/, although I don't care one way or another.
        -Eric