Re: Subversion performance (issue #1429 et al)
From: Brandon Ehle <azverkan_at_yahoo.com>
Date: 2003-08-18 16:54:21 CEST 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.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 vdeltaWhich 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'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.