[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

apr_file_copy performance on Win32

From: Will Dean <svn_at_indcomp.co.uk>
Date: 2004-10-31 22:56:54 CET


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

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

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

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! :-)



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

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.