Hi,
I found the single explanation on why 'svn update' is slow on Windows,
while it is fast on many other operating systems.
After creating a working copy with 207K files and 74K directories of +-
2.25 GB (2.8GB real diskspace) (=
http://svn.collab.net/repos/svn/branches/@35750 from a local mirror)
The costs of creating all the '.svn/lock' are more than 90% of the work.
On my Quad core Vista x64 machine with a single SATA drive, the cost of
a single 'svn update' that didn't retrieve any actual updates dropped
from about one minute average (Pretty random results, mostly by the
automatic slowdown of the CPU when the cores are doing nothing) to about
5 seconds after I removed all locking code. (Replaced by a simple apr
hashtable just to prove the issue).
To easily discover this issue you can just run
'svn status --show-updates'
This has to open all entry files too (to discover switched paths), but
has to check the working copy for changes too, while the update only has
to do this after receiving the data. This is about as fast as the update
removing the locking.
Reading all entry files and checking whether lock files exists (Not
disabled) are really cheap operations, but creating all these 8234 lock
files just to find that there are no changes really REALLY hurts. (And
it hurts even more when TSvnCache or a Virusscanner are monitoring all
file changes).
WC-NG will remove almost all of this locking, but the current status is
that Subversion 1.6 will be about 10% slower than 1.5.5 on Windows on
this svn update. (A single line patch to apr can compensate that a bit;
but I can't explain that 10% yet).
But that is at least months away and won't help the millions of Windows
users short term.
One of the solution I'm currently thinking about:
* Make the check for locked look up for a '.svn/recursive-lock' file in
itself and parent directories. (The result will be fully cached by a
disk cache)..
* Make the code that creates a depth infinity lock first create a normal
one level-lock and then place a .svn/recursive-lock and instead of just
adding a separate lock file in all directories, just check that there
are no existing lockfiles.
(on fail -> immediately remove recursive lock and return error)
This should move the pain of adding those 8234 from the update to a
possible second update that happens at the same time.
(I think the working copy format bump for the tree conflicts makes it
possible to change our locking strategy)
Suggestions and other solutions welcome,
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1134340
Received on 2009-02-10 15:15:34 CET