Critical 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
