[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion performance (issue #1429 et al)

From: Brandon Ehle <azverkan_at_yahoo.com>
Date: 2003-08-18 17:05:43 CEST

>>PS. Brandon, you mentioned something about more data (ra_dav/ra_svn)? I've
>> painfully experienced what it takes to gather this kind of data, your
>> help is very much appreciated.
>>
>>
I'm installing Linux on my second machine so that I can capture the
client/server results. After that, it'll take a few days for all of the
runs to finish.

>Out of curiousity (and ignorance), what *does* it take to gather this
>kind of data?
>
>
>
The hardest part is setting up your machine to capture the data in a
format which is useful to inspect.

OProfile is a quick and easy tool that tells you how Subversion performs
on this exact machine with the current setup. Setting it up isn't that
difficult and your software runs at full speed so the operations don't
take very long. Unfortunately realtime tools don't give you much
insight into the hierarchy of function calls and doesn't attribute.

Cachegrind is a completely different beast. I'm actually using the
calltree skin for valgrind available on the KCachegrind download page.
Running Subversion under cachegrind is painful at the very least as it
takes more than 12 hours to complete the checkout of Mozilla. Your code
is running under a virtual machine that walks through the entire program
line by line measuring its cache performance. While the results are
theoretical, it does give you detailed information about the hierarchy
of function calls throughout your program and the results are not
completely affected by the "Uncertainty Principle" like what some older
profilers give you (gprof). If you combine this knowledge of the
hierarchy with the some realtime results, it gives you a pretty decent
picture of the application.

I've still not found anyway of profiling IO load other than just running
"strace -c". I've still got some time to figure this out, though,
because Subversion is still very much CPU limited most of the time.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 18 17:12:37 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.