> -----Original Message-----
> From: Ruslan Sivak [mailto:russ_at_vshift.com]
> Sent: Thursday, February 05, 2009 10:48 PM
> To: Bert Huijben
> Cc: users_at_subversion.tigris.org
> Subject: Re: Speeding up workspace
>
> 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).
1.7 is scheduled for the second half of 2009, so it is on the horizon. (Some
developers are currently working on a branch to prepare the new working copy
as trunk is currently stabilizing for branching 1.6).
I'm not sure what else you can do...
Just make sure you use a recent 1.5 like 1.5.5 and not some older 1.5.2 or
something as we fixed a few windows performance issues since these early 1.5
releases.
If your framework changes the timestamps of files that can also slow down
subversion. If a file has the exact timestamp and size of the original file
subversion assumes it didn't change. If only the timestamp changes the file
has to be checked for changes by comparing it to the original file.
Just another suggestion, not really related to subversion but more to disk
performance: How much free ram does your pc have?
The ram prices dropped significantly over the last year.. and creating a
much larger disk cache certainly won't make your pc slower.
Bert
>
> Russ
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1109473
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-06 00:38:03 CET