On 12/17/07, Karl Fogel <kfogel@red-bean.com> wrote:
> kmradke@rockwellcollins.com writes:
> > For example:
> >
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 0 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 0 Length: 512
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 512 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 512 Length: 512
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 1024 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 1024 Length: 512
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 1536 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 1536 Length: 512
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 2048 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 2048 Length: 512
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 2560 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 2560 Length: 512
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 3072 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 3072 Length: 512
> > ...
> > READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
> > Offset: 1351168 Length: 512
> > WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
> > Offset: 1351168 Length: 512
> >
> >
> > A few things I noticed:
> >
> > 1) A file is named .tmp.tmp and stored in a "tmp" directory.
> > Isn't that a little redundant?
> >
> > 2) It appears to be reading the text-base file 512 bytes at a time
> > and then writing the (same???) 512 bytes out to the temp file.
> > Isn't that buffer size fairly small and inefficient?
> > Probably not noticeable on a local disk, but is quite an
> > impact when on a high latency network where the 512 byte packets
> > are acknowledged before the next one is transmitted.
> >
> > I'm hoping someone familiar with the working copy code can comment on
> > this behavior. I'd be willing to dig into this a little deeper, provided
> > someone that knows the code better doesn't give a valid reason for the
> > small buffer sizes. (I'll admit I am completely ignorant of the
> > working copy code, but I'm always willing to learn.)
>
> I don't have time to trace that buffer size down, but if you do,
> please let us know where it's happening. I too would expect the code
> to be using a much larger buffer size than that!
The buffer size comes from BUFSIZ which is used to copy files in APR.
They probably use BUFSIZ because the definition of the constant is
that it should return a buffer size for efficiently doing file IO.
Probably the CRT he's using is defining BUFSIZ to 512... (Which I
agree, is quite small...)
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 12:00:14 2007