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

Re: Subversion/Eclipse Performance on Windows

From: B Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Thu, 11 Dec 2008 14:05:58 +0100

On Wed, Dec 10, 2008 at 5:05 PM, B Smith-Mannschott
<bsmith.occs_at_gmail.com>wrote:

>
>
> On Wed, Dec 10, 2008 at 5:07 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
>
>> On Tue, Dec 9, 2008 at 23:00, David Weintraub <qazwart_at_gmail.com> wrote:
>> > It's mainly using Subversion for updating and checking out where they
>> > notice it slower. I know that Subversion has a lot more data that's
>> > brought over the network, and Windows is not good at transferring data
>> > over the network, but it should be faster than CVS in updating,
>> > diffing, revering, and other activities because it doesn't have to
>> > connect to the server to fetch a lot of data.
>> >
>> > We are using http:// w/ LDAP authorization, and FSFS. One programmer
>> > is saying that FSFS is what makes it so slow.
>> >
>> > Anyway, I was just curious whether or not this seemed to be an issue
>> > with anyone. Or whether Subclipse or Subversive was a better plugin
>> > for Eclipse.
>>
>> Is it the network access & server that's slow, or is it local
>> performance? Remember that Subversion pulls everything down into a
>> temp directory in the .svn directory, then copies it to the "real"
>> location. So disk I/O can be a killer. Especially if you're running an
>> on-access virus scanner.
>>
>
> I can second this. At my job most developers work on Windows with a
> locked-down scan-on-access virus scanner that seems to be set to "paranoid".
> Checking out jars is especially painful.
>
> I develop mostly an a linux box I put together myself. Much more pleasant.
> Much faster.
>

Just a datapoint:

In this scenario I'm checking out a single trunk over https from the central
svn server at my place of work. The resulting working copy consists of
21'239 files and 6'129 directories. (This count includes the administrative
stuff in the .svn directories.)

The server is running svn 1.4.x. Both clients are running a 1.5.x client.

svn -q co https://..../trunk the-trunk

(1) Windows XP; P4 HT_at_3GHz; NTFS; Single 7200 RPM HDD; McAffee virus scanner
active and scanning-on-access.

checkout takes 10 minutes

(2) Linux 2.6.24-22 32-bit (Ubuntu); Core2Duo @ 2.6GHz; EXT3; Dual 7200 RPM
HDD in RAID 1 (Which speeds up reads, but not writes); No virus scanner.

checkout takes 1 minute

Conclusion: My employer provided workstation sucks weasles for software
development. Other tests have tended to indicate that much of the blame
belongs to the antivirus software (and the operating system which makes it
necessary).

It is true and unfortunate that Subversion's working copy management
requires a lot of file individual file-system operations. Clearly this is
one area where Windows+NTFS+McAffee can't hold a candle to Linux.

For those stuck on Windows, one can hope that the working copy rewrite will
narrow the gap between Windows and Linux.

// Ben

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=982805

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2008-12-11 14:08:08 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.