"Ben Collins-Sussman" <sussman@collab.net> wrote in message
news:FCA5F0DA-2A82-11D9-B58F-000A95D699A0@collab.net...
>
> As has been discussed on this list many times before, win32 disk i/o is
> well-known to be pretty slow, much worse than unix. It's especially bad
> at reading/writing lots of tiny files, which is what the .svn/ area is all
> about. So your test results are no surprise to me.
To be fair to win32, some of the ways in which SVN/APR does file access are
particularly terrible on win32.
For example, this machine can easily copy a 8MB file on one disk in about
300ms. When SVN asks APR to copy the same file, it takes around 2 seconds,
merely because APR uses an absurdly small buffer to do the copy. (See a
message I posted elsewhere about this.)
I also suspect that the bad effects of A/V software (often most expensive on
a file open) are exacerbated by the fact that SVN will often open and close
the same files multiple times during an operation.
For example, when doing svn -v -n status in a tiny little leaf-node
directory (six versioned files, no subdirectories):
.svn/format is opened and shut six times.
.svn/entries is read completely, 3 times, apparently in 512 bytes chunks.
.svn/dir-props is opened and shut about 10 times.
etc, etc.
I'm not making any general criticism of SVN here - I think it's a great
system, and I admire the diligent, disciplined way in which the project has
been run. But I do think that it's quite some way short of the level of
optimisation at which it's appropriate to give up and say that what's left
is platform problems or secondary problems like A/V systems.
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 1 10:33:33 2004