Brandon Ehle wrote:
> 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.
Hm, I don't know where I got the megabyte sizes ... but you're right.
However, this would mean drastically reducing the vdelta window size,
which would really hurt both network performance and repository size.
Unfortunately, the algorithm itself is such that locality of data
references can't be improved.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 18 19:33:41 2003