You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Will Dean <sv...@indcomp.co.uk> on 2004/10/31 21:56:54 UTC
apr_file_copy performance on Win32
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
Re: apr_file_copy performance on Win32
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 2 Nov 2004, Will Dean wrote:
> "Peter N. Lundblad" <pe...@famlundblad.se> wrote in message
> news:Pine.LNX.4.55.0411022054280.8648@fnapp.local...
>
> I don't think anthing 'stat' is particularly standard.
>
Well, standard in POSIX, which is an ISO standard:-) But let's stop there.
> I would say
>
> #define APR_COPY_BLOCK_SIZE 65536
>
> would be as good a way of dealing with this as any.
>
Yes.
> > We have a special version of file copying already. Using our own loop
> > wouldn't be much code duplication. So, if this is a problem, we could do
> > this as a short-term solution.
>
> Are you saying that there's an equivalent copy function in SVN which is
> sometimes used instead of the APR version?
>
We have svn_io_copy_file, which calls apr_file_copy, but has some special
cases for permissions on Win32, since APR seems to be broken on that
platform. I'm proposing to just not use APR, but instead do our own copy
there.
> There does actually need to be a little bit of thought into the block size -
> in my very limited benchmarking here, copying a 8Meg-ish file, you get the
> following results:
>
> 512byte blocks - about 2 seconds
> 4096byte blocks (the default using fwrite/fread) - about 1 second
> 102400byte blocks (that's SVN_STREAM_CHUNK_SIZE) - about 800-900ms.
> any power of two sized block from about 16384 upwards - about 350ms.
>
> Although tiny blocks are slow for obvious reasons, there is clearly some
> other pathology here for larger block sizes, probably an interaction with
> underlying file-system block sizes (clusters, etc)
>
Clusters and page sizes and whatever.
> However, I'd be suprised if 65536 turned to be a bad choice on any system,
> and I can't believe it would be worse than 512!
>
A large power of two should be good, as you suggest.
> > Ofcourse, getting it into APR is even
> > better. Have you asked the APR people?
>
> I haven't dared. Would a change like this make it into APR and through to
> SVN in any human time-scale?
>
NO idea at all. Still, that would benefit other APR users as well. There
is nothing wrong with letting them know.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: apr_file_copy performance on Win32
Posted by Julian Foad <ju...@btopenworld.com>.
Peter N. Lundblad wrote:
> I don't think we need to go for the fastest copy algorithm in the world.
Indeed, we don't. And may I please urge you (whoever might write a patch) to
concentrate on fixing this in APR primarily. If it is a BIG problem for
Subversion users, then you could also supply a temporary patch for Subversion,
but it would be sad to patch only Subversion.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: apr_file_copy performance on Win32
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 2 Nov 2004, Will Dean wrote:
> "Peter N. Lundblad" <pe...@famlundblad.se> wrote in message
> news:Pine.LNX.4.55.0411022230030.13608@fnapp.local...
> >>
> Of course, overwhelmingly the simplest way to get an OS's input on the
> subject of file copying is just to call its file copying API and let it deal
> with the details. (Though I think that on Win32 there are specific
> situations where there are techniques which are faster than CopyFile.)
>
I don't think we need to go for the fastest copy algorithm in the world. I
thik a patch that just does its own copying with, say a 64k buffer, would
be nice.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: apr_file_copy performance on Win32
Posted by Will Dean <sv...@indcomp.co.uk>.
"Peter N. Lundblad" <pe...@famlundblad.se> wrote in message
news:Pine.LNX.4.55.0411022230030.13608@fnapp.local...
>>
> According to the spec:
> blksize_t st_blksize A file-system specific preferred I/O block size for
> this object. ...
I would think that it's quite hard for the OS to express a useful general
'preference' here. It might be assuming that you were going to be doing
lots of fgetc-type access, and think that something like 4096 bytes would be
sensible.
Of course, overwhelmingly the simplest way to get an OS's input on the
subject of file copying is just to call its file copying API and let it deal
with the details. (Though I think that on Win32 there are specific
situations where there are techniques which are faster than CopyFile.)
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: apr_file_copy performance on Win32
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
[Starting to get OT]
On Tue, 2 Nov 2004, Michael Sweet wrote:
> > I don't think anthing 'stat' is particularly standard.
>
> "stat" is a POSIX API... That said, st_blksize is just the inode
> size of the underlying filesystem (on UNIX/Linux anyways) and says
> nothing about the overhead of system calls, so...
>
According to the spec:
blksize_t st_blksize A file-system specific preferred I/O block size for
this object. ...
I agree with the rest of your post.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: apr_file_copy performance on Win32
Posted by Michael Sweet <mi...@easysw.com>.
Will Dean wrote:
> "Peter N. Lundblad" <pe...@famlundblad.se> wrote in message
> news:Pine.LNX.4.55.0411022054280.8648@fnapp.local...
>
>
>>I don't think BUFSIZ is the modern way of choosing a buffer size. Usually
>>one uses st_blksize from a stat call, but that seems not to be available
>>in APR.
>
>
> I don't think anthing 'stat' is particularly standard.
"stat" is a POSIX API... That said, st_blksize is just the inode
size of the underlying filesystem (on UNIX/Linux anyways) and says
nothing about the overhead of system calls, so...
> I would say
>
> #define APR_COPY_BLOCK_SIZE 65536
>
> would be as good a way of dealing with this as any.
> ...
If you were really anal about performance, you'd probably use a
small multiple of the st_blksize value, but I think 64k should be
safe enough...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: apr_file_copy performance on Win32
Posted by Will Dean <sv...@indcomp.co.uk>.
"Peter N. Lundblad" <pe...@famlundblad.se> wrote in message
news:Pine.LNX.4.55.0411022054280.8648@fnapp.local...
> I don't think BUFSIZ is the modern way of choosing a buffer size. Usually
> one uses st_blksize from a stat call, but that seems not to be available
> in APR.
I don't think anthing 'stat' is particularly standard.
I would say
#define APR_COPY_BLOCK_SIZE 65536
would be as good a way of dealing with this as any.
> We have a special version of file copying already. Using our own loop
> wouldn't be much code duplication. So, if this is a problem, we could do
> this as a short-term solution.
I don't think I follow this paragraph!
Are you saying that there's an equivalent copy function in SVN which is
sometimes used instead of the APR version?
There does actually need to be a little bit of thought into the block size -
in my very limited benchmarking here, copying a 8Meg-ish file, you get the
following results:
512byte blocks - about 2 seconds
4096byte blocks (the default using fwrite/fread) - about 1 second
102400byte blocks (that's SVN_STREAM_CHUNK_SIZE) - about 800-900ms.
any power of two sized block from about 16384 upwards - about 350ms.
CopyFile does a copy in 65536byte chunks and takes around 350ms.
Although tiny blocks are slow for obvious reasons, there is clearly some
other pathology here for larger block sizes, probably an interaction with
underlying file-system block sizes (clusters, etc)
However, I'd be suprised if 65536 turned to be a bad choice on any system,
and I can't believe it would be worse than 512!
> Ofcourse, getting it into APR is even
> better. Have you asked the APR people?
I haven't dared. Would a change like this make it into APR and through to
SVN in any human time-scale?
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: apr_file_copy performance on Win32
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 31 Oct 2004, Will Dean wrote:
> 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.)
>
I don't think BUFSIZ is the modern way of choosing a buffer size. Usually
one uses st_blksize from a stat call, but that seems not to be available
in APR.
We have a special version of file copying already. Using our own loop
wouldn't be much code duplication. So, if this is a problem, we could do
this as a short-term solution. Ofcourse, getting it into APR is even
better. Have you asked the APR people?
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org