> -----Original Message-----
> From: Bert Huijben [mailto:rhuijben_at_sharpsvn.net]
> Sent: dinsdag 10 februari 2009 15:15
> To: dev_at_subversion.tigris.org
> Subject: Locking strategy (= Windows wc-update performance down the
> drain)
>
> 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).
Responding to irc:
<@hwright> Bert: yeah, the 10% slowdown is what concerns me.
Note: I ignore the difference between 1.5.5 and 1.6 here...
(My profiler results will return more useful data if I remove this 90% case
first. My pc decides it can slowdown the CPU while updating, because it is
using one clock minute with virtually no cpu since r35731, r35732).
I'm not really interested in looking through the update code on what might
cause this few percent loss before I can find a solution for the other
slowdown.
> 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&dsMessageI
> d=1134340
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1134550
Received on 2009-02-10 16:19:07 CET