"Norbert Unterberg" <firstname.lastname@example.org> wrote on 12/18/2007 06:27:06
> On Dec 18, 2007 12:05 PM, Erik Huelsmann <email@example.com> wrote:
> > On 12/18/07, Norbert Unterberg <firstname.lastname@example.org> wrote:
> > > You are on the wrong track here.The problem is not what BUFSIZ is
> > > defined on the different platforms but how APR uses it.
> > > BUFSIZ is the size of the buffer that can be set for buffered
> > > with the setbuf() call. Nothing more. MSDN just says: "BUFSIZ is the
> > > required user-allocated buffer for the setvbuf routine." BUFSIZ is
> > > a suggestion for a buffer size when dealing with large binary files.
> > > So the bug is in APR where BUFSIZ is used for something it was
> not designed for.
> > >
> > > This has already been discussed for years on this list, but
> nothing has changed:
> > >
> > >
> > >
> > > So it is clearly an apr and not a windows issue.
> > Providing a patch might help:
> Thank you for the invitation, but no thank you. Diagnosing if someone
> is ill and actually performing the operation are two different things,
> and I currently do not want to jump over the high hurdles of actually
> creating a politically and stylistically correct patch to an APR
> library function!
> > They define a buffer size of their own
> > (APR_FILE_BUFSIZE, defined to 4096 on Win32) which should probably be
> > used for binary file copies since it's used for buffered files as
> > well.
> As already suggested three years ago, why not call the native
> CopyFile() function on Windows which will likely have best possible
> performance without filling with different buffer sizes?
Nice to know I've stumbled across a 3 year old problem. I can't believe
file copying is implemented so potentially inefficiently.
I just checked apr-1.2.12, and it is still using BUFSIZ in the
I may submit a patch to the APR people to see what they think. However,
I really wonder if Subversion should just be doing it's own thing here
until/when APR is improved. Subversion does a lot of file copying and
this could be a big working copy performance improvement on slower
Since I have a unix build environment (not windows where I observed this
behavior), I may do some adhoc testing over nfs to see if/how it really
affects working copy performance.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Dec 18 16:54:59 2007