[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 16:54:21 CEST
Branko Čibej wrote:
Sander Striker wrote:

  
Now if I'm reading things right:

svn_fs_file_md5_checksum   8.63%
svn_fs_is_dir              9.52%      (19.78%)
send_text_delta           16.10% *
delta_proplists           18.58%      (20.74%)
delta_dirs                13.82% **   ( 1.40%)
svn_wc__run_log           14.50%

* 8.66% of which in vdelta

    
Which is horrible, especially since vdelta seems to get a lot of cache
misses. I wonder if those are caused by our appending new ops to a
vector while at the same time madly hopping around ~1M of source, target
and hashtable buffers, and what would happen if I went and interleaved
the ops list into the hash table. It would double the hash table size,
but modern CPUs should be able to put 2M into data cache with no problem
at all.
  
I'm not exactly sure what you are trying to say here.  But I believe if we want vdelta to become a very fast operation that it needs to try and fit its hash table and buffers into the L1 cache.   On current CPU's, we can probably expect that cache size to be 128KB, but if we want to support older CPU's in the 500MHZ-2000MHZ, we probably need to be able to fit all of that into 64KB of memory.
I'll try to reproduce the test case, then see what happens if I fiddle
with the allocation order in vdelta.

  

--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org For additional commands, e-mail: dev-help@subversion.tigris.org Received on Mon Aug 18 16:55:11 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.