SVN update client performance under windows
von Gaylord, am 2 Oktober 2009 - 0 Kommentare
After i re-entered the open source version management area again (used Perforce for years and i know why ;-) ) i now work in a project with a lot of external partners and now we use Subversion.
While most others have no problems with update performance, it is horrible for me. Our repository consists of 8 GB and a couple of thousand files and our current revision number is 18644. So nothing specatcular (with perforce we were in the 1 Million change lists area).
Now clicking on "UPDATE" on my nice Vista notebook takes up to 5 minutes before the first files are actually transferred. While there was only little network traffic, HDD is working like mad. I could not explain that and so i searched for reasons online.
First i suspected Tortoise to be the bad guy. But after i had de-installed it and used command line SVN i learned that it is not the case (Tortoise has its oddnesses, but my bad update performance was obviously not linked to it). Also, our server is not the problem. It works fast for other clients. Eventually i found this blog post, that gives a hint:
Obviously SVN is using a lot of small files to lock the local copy. And under windows this kills performance especially on notebook-hdds. The statement seems to be: Wait for 1.7 and then the locking mechanism for SVN will be replaced by something more optimized for Windows Platform.
In the meantime i will have a look for acceleration for handling of a lot small writes for NTFS...
Update: I have now enabled "write caching" and "performance optimization" for the harddrive i use with SVN. Unfortunately that still does not do it. SVN UP still takes 5 minutes. What i see is 100+ page faults per second, but no significant network I/O and also not too much HDD throughput (1 MB/sec).