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

Re: How to speed up subversion

From: David Brodbeck <brodbd_at_u.washington.edu>
Date: Tue, 25 May 2010 10:01:20 -0700

On May 25, 2010, at 9:59 AM, Les Mikesell wrote:

> On 5/25/2010 11:44 AM, David Brodbeck wrote:
>>
>> On May 24, 2010, at 2:05 PM, Les Mikesell wrote:
>>
>>> On 5/24/2010 3:51 PM, David Brodbeck wrote:
>>>>
>>>> On May 21, 2010, at 8:23 AM, Hyrum K. Wright wrote:
>>>>> Actually, Subversion is a bit more intelligent about it, attempting to use modification times and sizes, before doing a byte-by-byte comparison.
>>>>
>>>> Even that can be slow if there are lots of files involved. Note that some filesystems have particularly bad performance if there are lots of files in a single directory, as well. This is especially true of NFS. In one extreme example, I've seen a simple "ls" take tens of minutes to produce any output in an NFS-mounted directory with ~1,000,000 files.
>>>
>>> But to be fair, note that ls sorts its output, so it can't output anything until it has read everything.
>>
>> True, but other operations were slow, too. The way readdir() works means that a lot of file operations inevitably involve a linear search of the directory.
>
> And worse, creating a new file involves doing that search first to see if it is new, then finding a free slot or growing the directory and adding it all as an atomic operation, blocking any other process trying to do the same. But, that's why subdirectories were invented - you don't have to put everything on one big inefficient space.

Yup. Now I just need to convince my users of that. ;)

-- 
David Brodbeck
System Administrator, Linguistics
University of Washington
Received on 2010-05-25 19:03:06 CEST

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.