[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-27 00:40:03 CEST

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.

Personally I want all svn API to support 0, 1, infinite. In a GUI I use
depth=1 all the time
and find the performance problems a huge issue that I will have to work
around until the API catches up.
svn_client_ls has the problem that it only support depth=1 and
depth=infinity, where depth=0 is needed.

>> 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?

Windows XP PRO on a 1GHz PIII 512MB memory svn 1.1.1. Hmmm is the virus
protection a factor... I'll have to test.
I also run the same tests on Mandrake 9.2 and see how it compares.

I driving svn thru pysvn calling svn_client_proplist once/file on 54
files. vs.
pysvn calling svn_client_proplist recursive on the the dir containing
the same 54 files.

> May I suggest that, to begin with, we investigate why some things are
> slow, before we consider adding a new API function.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 27 00:41:09 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.