Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-3369

Locking strategy inadequate for decent Windows Performance

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: all
    • Fix Version/s: 1.7.0
    • Component/s: libsvn_wc
    • Labels:
      None
    • Environment:

      Windows XP

      Description

      [This issue applies to the original Subversion 1.X working copy library as used 
      in Subversion 1.0-1.6]
      
      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=1134550

        Attachments

        Issue Links

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              rhuijben Bert Huijben

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment