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
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
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Jun 1 14:35:35 2002