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

Re: CVS/Subversion/Perforce Timing Statistics (Take 3)

From: mark benedetto king <bking_at_answerfriend.com>
Date: 2002-05-30 15:12:48 CEST

On Thu, May 30, 2002 at 02:11:18AM -0700, Greg Stein wrote:
> Certainly, there are some spot-improvements that could be done right now
> (e.g. rather than open/close .svn/README to test for an admin dir, we could
> just stat() the file). Finding those spots will need a different type of
> analysis tho. Finding larger types of fixes would probably be best in
> another month or so.
>

A week or so ago, I straced an "svn co" of the svn trunk, and compiled
some numbers. 177 of 224 wall-clock seconds were spent in select(), waiting
on the server. The next highest was write(), at 1 wall-clock second.

The total amount of time spent in all system calls was 186 seconds.

That means that making the server infinitely fast would reduce wall-clock
time to 47 seconds, only 9 of which would be in write/open/close/unlink/mkdir
etc.

To summarize: less than 20% of the client's work was syscall-bound on
my test, and the total amount of time in the client was less than 21% of
the total time for the co. This means to me that optimizations on the
client should focus on the 80%, non-syscall related portion. I'll do
some poking around with gprof to see where this might be.

Soon, I'll try with a local httpd in order to reduce the effects of network
throughput and latency. I suspect this will cut the 80:20 server:client
ratio down.

I also want to measure using ra_local, but that (obviously) makes separating
wc profiling work from ra profiling work tricky. The client/server boundary
provides a nice wall that gprof cannot cross. :-)

Another interesting bit of data from strace: we are reading and rereading
and rerereading .svn/entries files like *crazy*. The open/read is cheap
because the fs caches, but I wonder what the performance implications of
parsing them again and again are. A few of the worst offenders:

svn/subversion/libsvn_fs/.svn/entries: 438 times
svn/subversion/clients/cmdline/.svn/entries: 380 times
svn/subversion/bindings/java/jni/.svn/entries: 378 times
svn/subversion/clients/win32/WinSVN/.svn/entries: 315 times

There are 88 .svn/entries files, and they are opened (and I presume
subsequently read) a total of 8153 times.

I suppose I need to take a look at the checkout process itself to
understand why they're being read and reread so many times.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:35:35 2002

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