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

Re: Poor performance in windows. Switching back to CVS

From: Talden <talden_at_gmail.com>
Date: 2007-02-13 22:21:58 CET

Knowing the filename doesn't mean you know where it is on the disk.

'find' from a file-system point of view means resolving a
path+filename to a location on disk. This degrades as the number of
paths in the file-system increases. The mechanism used to store the
lookup tables for these files affects performance and degrades in
different ways depending on the technique and sometimes the pattern of
the paths themselves (some file-systems are very fast at resolving the
filename given a folder node, others lump all path+file names into a
single storage structure that is fast to search but slow to update.

NTFS, I've heard, is known to suffer with very large numbers of files
per folder. I have no idea of the performance degradation pattern of
the EXT file-system.

--
Talden
On 2/14/07, Jeff Smith <jsmith@robotronics.com> wrote:
> On Monday 12 February 2007 15:01, Talden wrote:
> > PS: At which point does ext3 begin to suffer for having too many
> > revision files in the FSFS back-end?  IE an update or a checkout
> > has to find these by name - surely even in ext3 finding the
> > appropriate file is a function of the number of files.  I ask this
> > because initial smaller, more manageable cvs2svn converts suggest a
> > full conversion will yield upwards of 60,000+ revisions - should I
> > be considering BDB?
> >
> > --
> > Talden
>
> Interresting question... what do you mean by "find", does it not
> already know the path?
>
> I think that so long as the file system itself handles that many files
> (for example not running out of inodes), then the only thing is more
> files take longer to read and process. That should be expected, and
> no version control system would be unaffected by the increase.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 13 22:22:29 2007

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.