[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Speeding up workspace

From: Ruslan Sivak <russ_at_vshift.com>
Date: Thu, 05 Feb 2009 16:47:32 -0500

Bert Huijben wrote:
> You should really look at what programs are monitoring your disk.
> E.g.:
> * Is a virusscanner reading every file that is read and written. And
> especially if it locks the file when it is scanning. (I would recommend just
> scanning on write in your workingcopies)
> * Is TortoiseSVN's status cache monitoring this directory? (If it detects a
> change it scans for status updates.. slowing down other clients by using
> your harddisk when you need it yourself).
> Just performing a 'svn update' that doesn't touch much files shouldn't take
> more than a few seconds on that number of files/folders.
> An average of 2 files per folder is not high... Subversion 1.0-1.6 performs
> better with a bit more files/folder.. The new workingcopy format that is
> expected in 1.7 should resolve these differences and should be /a lot/
> faster for this low file-directory ratio.
> Bert

With the virus scanner turned off and Tortoise cache turned off, it's
still very slow. I think you are right about the high directory/file
ratio - If I do an update on the part that's just media, which is 9.9GB
(13.1GB on disk), 65k files, 8.5k folders, it updates in about 30 seconds.

If I do it on the code folder, which is 96.3MB (2.68GB on disk), 44k
files, 46k folders, it takes 2 minutes, 5 seconds.

This is after a fresh update, so a lot of things are already cached.

We are using a framework which keeps a lot of empty folders. I'm not
sure if it's safe to delete them. Is there anything we can do to speed
things up in our situation short of waiting for 1.7 (which probably
wont' be out for a few years).



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-05 22:48:42 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.