More analysis:
More info derived from Brandon Ehles profiling data.
Library | Cycles (%) | L1 Read*(%) | L2 Read*(%)
----------------------------------------------------------------------
libdb-4.0.so | 25.88 | 28.49 | 17.54
libapr-0.so.0.9.4 | 19.61 | 11.07 | 24.93
libsvn_fs-1.so.0.0.0 | 13.89 | 02.44 | 01.66
libc-2.3.2.so | 10.78 | 09.44 | 14.95
libsvn_delta-1.so.0.0.0 | 10.50 | 39.12 | 17.76
libaprutil-0.so.0.9.4 | 08.61 | 01.65 | 01.70
libsvn_subr-1.so.0.0.0 | 06.03 | 04.59 | 14.11
libexpat.so.0.4.0 | 01.57 | - | 01.44
ISO8859-1.so | 01.40 | - | -
libsvn_wc-1.so.0.0.0 | 01.16 | 01.80 | 04.49
*) read cache misses
Well, that's a surprise. I expected to see libsvn_wc a lot higher up. The
focus should be on libsvn_fs and libsvn_delta according to these figures.
Or not :). The numbers don't take into account how much time is spent in
libc, apr, etc., due to calls from libsvn_wc. It would be nice to have a tool
that could calculate how much time can be attributed to each lib. Probably
wouldn't be too hard to do. Also note that the percentages aren't real time,
but rather CPU cycles. The real time analysis could point at libsvn_wc after
all.
First let's take a look at libsvn_fs. It seems like 28.35% of the time spent
in there is in svn_fs__rep_contents. Upon closer inspection that is made up
of:
[1] svn_fs__rep_contents_size 10.23%
[2] rep_read_range 9.82%
[3] svn_fs__bdb_read_rep 3.81%
[4] apr_md5_xxx 4.49%
[1] and [2] have a lot in common when looking at their call graph. Would
it be possible to do some combining of svn_fs__bdb_string_size and
svn_fs__bdb_string_read?
Mike already tackled a problem with respect to svn_fs_is_dir/file.
See this thread http://www.contactor.se/~dast/svn/archive-2003-08/0750.shtml
and rev #6774.
Note that if we can optimize libsvn_fs, we most likely also reduce the time
spent in libdb.
libsvn_delta is using up 10.50% of our cycles, of which vdelta is using
8.67%. The same function is responsible for 38.40% of the L1 read misses
and 16.41% of the L2 read misses. Definitely one to look into.
Sidenote, another 12.44% of the L2 read misses is due to apr_hash_next.
And 11.38% in svn_path_is_child.
Sander
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 18 15:38:45 2003