Hi,
We're using SVN here on a project with (as well as a lot of typical source
code) a large number of large (generally small numbers of megabytes) binary
files.
Though SVN is a great product, performance doesn't always feel particularly
sparkling, and I've been looking around for any obvious timewasters. I am
aware that large binary files on Win32 is not right in the mainstream of SVN
development.
One of the things we've noticed is that file-copies between temporary files
and text-base files are done by doing read-writes of 512 byte chunks. On
any vaguely modern PC, a buffer this small would seem to be better suited to
a stress test of the operating system's disk-caching than to an efficient
copy of a large file.
This copy is being done by apr_file_transfer_contents, which uses the
CRT-provided const BUFSIZE to set the size of its chunk buffer. On current
MS compilers, this is defined as 512. I'm not convinced (from reading the
spec) that this constant is provided by ANSI 'C' as a general purpose 'use
this buffer size in your file operations' value, and I suspect that 512
bytes is *way* smaller than anything any of us would choose for a buffer
size in this role. (I note that elsewhere, SVN uses SVN_STREAM_CHUNK_SIZE
for similar functions, which is a much more respectable size.)
Of course, I actually think that there should be a Win32 specialisation of
the APR copy.c module which calls the native CopyFile function and then
deals with whatever strange permissions stuff crops-up afterwards. I
recognise that this is a much higher-risk than just changing the buffer
size?
My questions is, is it possible, or likely, that something like this will
get improved in APR? Is it worth me asking the APR people about this
directly, or do the SVN team have sufficient clout as APR's most famous
3rd-party users that they could get something changed here?
I appreciate that the intersection of SVN dev interest, Win32 only and
'potential perf problem' is vanishingly small! :-)
Thanks,
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 31 22:57:36 2004