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!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 09:47:30 2007