Hi Stefan,
Stefan Fuhrmann writes:
> My measurements seem to support what Philip wrote:
> The expensive part is run on the server. Even with my
> optimized server, the svnrdump CPU usage is less than
> the time taken by the server. Some numbers (hot file
> cache):
>
> svnadmin dump
> 1.7 trunk 70s real 66s user 4s system
> perf-branch 30s real 28s user 2s system
>
> 1.7 trunk svnrdump
> ra-local 88s real 81s user 7s system
> svn: (1.7 trunk) 99s real 6s user 4s system
> svn: (perf-branch, cold) 72s real 5s user 6s system
> svn: (perf-branch, hot) 17s real 5s user 5s system
>
> Thus, svnrdump is slower only for ra-local where it is
> of no particular use in the first place. To really speed
> things up, the caching infrastructure from the performance
> branch should be merged into /trunk.
Wow, that looks awesome. Yeah, Daniel suggested that I run svnrdump
against your perf branch yesterday, but I wasn't able to get your
branch to build:
subversion/libsvn_subr/svn_file_handle_cache.c:890: error: 'svn_file_handle_cache_t' has no member named 'mutex'
What exactly are the changes that "hot" introduces- can you point me
to the specific revision numbers that we intend to merge?
> >@Stefan: Thoughts on hacking APR hashtables directly?
> >
> Are you sure?! Which operation is the most expensive one
> and how often is it called? Who calls it and why?
My bad. I got muddled up when using ra_local: when I saw lots of MD5
functions, I assumed it had to do something with the hashtable since
the checksum was caculated by server-side. The profiler profiled both
server-side and client-side. Over svn://, I got a much cleaner
output. The new results indicate:
1. Server-client IO is the major bottleneck, as Philip and you pointed
out.
2. On the client side, the major bottlneck is the IO during textdelta
application. David (CC'ed now) and I are trying some experiments
with a single temporary file. Thoughts?
> At least the results are much more useful when there is
> a tool like Kcachegrind that allows easy navigation though
> the huge amount of information that was gathered.
Yep! The visualizer is quite awesome :)
-- Ram
Received on 2010-09-30 04:30:30 CEST