subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Rowell <geoff.row...@gmail.com>
Subject Re: Checkout really slow in Windows with lots of files in one directory
Date Wed, 02 Feb 2011 12:41:10 GMT
On Wed, Feb 2, 2011 at 4:09 AM, Nick <nospam@codesniffer.com> wrote:
> On Tue, 2011-02-01 at 13:00 -0500, Mark Phippard wrote:
>
> On Wed, Jan 26, 2011 at 9:28 AM, Neil Bird <neil@jibbyjobby.co.uk> wrote:
>
>>  We have a graphics-oriented code-base that's auto-generated and has >5000
>> source files in one directory.  While I can check this out OK on Linux,
>> we're seeing an unusable slow-down on Windows XP (NTFS), both using
>> Tortoise
>> directly, and as a test on Linux with the Windows drive mapped over CIFS.
>
> I created a folder with 5001 files in it ... maybe that is not enough?
>  I just used small simple text files as I was only checking for the
> general problem in managing the temp files and the WC metadata.
>
> Upon checkout (using 1.6.15 command line client) I did not notice any
> slowdown.  Windows checked out via HTTP across internet in about 49
> seconds as opposed to 33 from my Mac (which is a faster system).  The
> main thing is checkout did not seem to slow down.
>
> I did a similar test, using 5100 files in a single directory.  Each file
> contained only the content "file XXXX" where XXXX was the number of the file
> (so tiny files).  My linux system took 17 seconds, while Windows took a bit
> less than 2 min (but Windows is virtualized while linux is on the
> hardware).  I also did not notice a slow-down as the checkout proceeded.
> Both systems used 1.6.15 and accessed the repo via https.
>
> I did, however, notice that the time to *add* the files (done via svn add
> *.txt) seemed to progressively slow down.  But this was only observed by
> watching the files in the console as they were being added (it was
> relatively easy to see the rate because the each file name had a linear
> number at the end).  I don't have any timings to back this up, though I'll
> collect some if anyone's interested.
>
I don't know why, but I believe the key thing here is working with
*binary* files.

I noticed the same problem with a massive (10K+) amount of audio
snippets in a single directory.
-- 
Geoff Rowell
geoff.rowell@gmail.com

Mime
View raw message