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

Re: Performance issues versus CVS

From: John Peacock <jpeacock_at_rowman.com>
Date: 2004-04-19 22:54:30 CEST

Keven Ring wrote:

> solo turn wrote:
>> since 0.33 using linux as client (i just tried with reiserfs) is very
>> fast (10 times as fast as windows),

> Still, the times between CVS and an SVN server shouldn't be *THAT* far
> off. I can understand that the HTTP would be a bit slower due to the
> extra chattiness of it, but still not 10x slower!

Solo was saying that Windows client was 10x slower than Unix client, which I can
certainly find plausible. NTFS is not well suited for lots of small files (with
default settings); changing the parameters can yield suprising increases in

One feature of NTFS is that the block size is also the size of a node in the
directory information structure, and that if the file is actually small enough,
it will be stored in the directory structure instead of as a seperate file in
the filesystem. This method can lead to more slack space (allocated but unused
space on the drive), but storage is so cheap, I would rather waste space than
time. I used an 8k block size for an NTFS mail application and noticed a
definite performance boost.

OTOH, this has no bearing on your issue, since you are using Fedora Core 1.
What would be useful is to find out what filesystem you are using on the
partition where your WC is loaded. For example, if you are using a Samba share
or NFS, there are known performance penalties for storing your files on a
networked share.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 19 22:54:27 2004

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

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