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

Re: svn_client_proplist slow to get all of one dir

From: Barry Scott <barry_at_barrys-emacs.org>
Date: 2004-10-30 12:53:37 CEST

I have created a test program test_propval.cpp in

I run the program in the Patches directory with the command line

test_propval readme.txt 100

Running on a 600MHz Mandrake 9.2 system I get:

         Time for 100 calls 170ms
         Time for 1 call 1ms

Running on a 1GHz Windows XP SP1 systems with Norton
anti-virus enabled:

         Time for 100 calls 2423ms
         Time for 1 call 24ms

Running on a 1GHz Windows XP SP1 systems with Norton
anti-virus disabled:

         Time for 100 calls 1392ms
         Time for 1 call 13ms

The performance on Linux is fine, but the Windows performance is

Why is the windows performance so poor?


On Oct 26, 2004, at 00:15, Julian Foad wrote:

> Barry Scott wrote:
>> I'd like to see a version of svn_client_proplist that can return all
>> the properties of
>> all the files in a single directory.
> Well, I'm in two minds about whether we should support all three of
> "depth=0", "depth=1" and "depth=infinity" recursion behaviours, at the
> command-line interface and at API level. One part of me says that
> "depth=1" is one particular case that can be built up from "depth=0"
> and shouldn't be specially supported. But the other side of me
> acknowledges that it is a commonly desired result.
>> At the moment the two choices have problems:
>> 1. get all recursive - returns for all sub directories, not what I
>> want
>> 2. get one files props - far too slow, takes 1.773s for 54 files vs.
>> recusive returning 54 in 60ms
> In a WC I'm not seeing it this slow: for me, "svn pl * */*" takes
> 0.22s real time for 40 files. (I assume that is calling
> svn_client_proplist 40 times.) On the other hand, for a "file://" URL,
> it is taking more than 1s per file for me! This is on Linux on a 500
> MHz Pentium III. What is your system and test?
> May I suggest that, to begin with, we investigate why some things are
> slow, before we consider adding a new API function.
> - Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 30 12:54:51 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.