By the way, although I haven't been that involved in this discussion,
I'd just like to point out that this is a textbook example of why we
ask people to test the prereleases and release candidates. I wish
more people would.
Thanks for the good discussion and followup; this will probably be
fixed
writes:
> -> sqlite3 .svn/wc.db "select parent_relpath, count(*) AS n from nodes group
> by parent_relpath order by n desc limit 1"
> ip/DESIGNWARE/verilog|211
That's about 2.5 times the size of a Subversion trunk wc, both in number
of nodes and biggest directory.
If I "svn add" a few hundred
NG,MICHAEL (A-ColSprings,ex1)
Cc: d...@daniel.shahaf.name; dev@subversion.apache.org
Subject: Re: Really lousy performance with svn info --depth infinity
Philip Martin writes:
> Does your working copy have "large" directories, i.e. a directory with
> a large number of immediate
iel.shahaf.name; dev@subversion.apache.org
Subject: Re: Really lousy performance with svn info --depth infinity
writes:
> And here is the final comparison using an nfs mounted working copy.
> This is where the difference gets really bad.
>
> 1.6.17
>
> -> time /file_access/su
Philip Martin writes:
> Does your working copy have "large" directories, i.e. a directory with a
> large number of immediate subdirs/files? (It should be possible to
> forumulate an SQL statement that tells me, but my SQL isn't good
> enough).
Thanks to Daniel:
$ sqlite3 .svn/wc.db "select par
: Re: Really lousy performance with svn info --depth infinity
Daniel Shahaf writes:
> So presumably the second one should really be:
>
> % svn ls -R >f
> % time xargs svn info http://www.uberSVN.com
writes:
> And here is the final comparison using an nfs mounted working copy.
> This is where the difference gets really bad.
>
> 1.6.17
>
> -> time /file_access/subversion/1.6.17/bin/svn info --depth infinity >
> /dev/null
>
> real0m2.548s
> user0m0.350s
> sys 0m0.142s
>
> 1.7.0-rc2
Daniel Shahaf writes:
> So presumably the second one should really be:
>
> % svn ls -R >f
> % time xargs svn info http://www.uberSVN.com
So presumably the second one should really be:
% svn ls -R >f
% time xargs svn info Bert Huijben writes:
>
> > No, svn ls doesn't. It just obtains the URL and revision and then
> > queries the repository.
>
> The output of "svn ls" is fed to "svn info"
>
> This is one recursive call:
>
> >>
af.name; dev@subversion.apache.org
Subject: Re: Really lousy performance with svn info --depth infinity
writes:
> And here is the comparsion of 1.6.17 vs 1.7.0-rc2. This test was run
> on a locally mounted drive, it gets significantly worse on an nfs
> mounted drive.
>
> 1.6.17
>
> -> tim
Philip Martin writes:
> At first glance the difference between recursive and non-recursive is
> node.c:walker_helper. Is STMT_SELECT_NODE_CHILDREN_WALKER_INFO missing
> an index?
Look at the comment:
-- STMT_SELECT_NODE_CHILDREN_WALKER_INFO
/* ### See comment at STMT_SELECT_NODE_CHILDREN_INFO.
Bert Huijben writes:
> No, svn ls doesn't. It just obtains the URL and revision and then
> queries the repository.
The output of "svn ls" is fed to "svn info"
This is one recursive call:
>> svn info -depth infinity
This is multiple non-recursive calls:
>> svn ls -depth infinity | xargs svn i
writes:
> And here is the comparsion of 1.6.17 vs 1.7.0-rc2. This test was run
> on a locally mounted drive, it gets significantly worse on an nfs
> mounted drive.
>
> 1.6.17
>
> -> time /file_access/subversion/1.6.17/bin/svn info --depth infinity >
> /dev/null
>
> real0m0.225s
> user0m
No, svn ls doesn't. It just obtains the URL and revision and then
queries the repository.
Bert Huijben (Cell phone) From: Philip Martin
Sent: donderdag 1 september 2011 18:00
To: Bert Huijben
Cc: michael_rytt...@agilent.com; dev@subversion.apache.org
Subject: Re: Really lousy performance wit
s,ex1)
Cc: d...@daniel.shahaf.name; dev@subversion.apache.org
Subject: Re: Really lousy performance with svn info --depth infinity
writes:
> Svn info --depth inifinty
WC on local disk or network disk?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
ICHAEL (A-ColSprings,ex1); dev@subversion.apache.org
Subject: Re: Really lousy performance with svn info --depth infinity
"Bert Huijben" writes:
> These operations do very different things. The first reads your
> working copy to obtain a lot of details (unless you pass a revision;
writes:
> Svn info --depth inifinty
WC on local disk or network disk?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
A-ColSprings,ex1)
> Cc: dev@subversion.apache.org
> Subject: Re: Really lousy performance with svn info --depth infinity
>
> writes:
>
> > Quick question. I would expect the following 2 commands to perform
> > equivalent functions.
> >
> > svn info -depth infinity
> >
ubversion.apache.org
> Subject: Re: Really lousy performance with svn info --depth infinity
>
> writes:
>
> > Quick question. I would expect the following 2 commands to perform
> > equivalent functions.
> >
> > svn info -depth infinity
> > svn ls -dept
"Bert Huijben" writes:
> These operations do very different things. The first reads your
> working copy to obtain a lot of details (unless you pass a revision;
> in that case it looks at the repository)
>
> The second asks the repository what files there are below the current
> directory in the r
[mailto:philip.mar...@wandisco.com]
Sent: Thursday, September 01, 2011 9:52 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: dev@subversion.apache.org
Subject: Re: Really lousy performance with svn info --depth infinity
writes:
> Quick question. I would expect the following 2 commands to perf
writes:
> Quick question. I would expect the following 2 commands to perform
> equivalent functions.
>
> svn info -depth infinity
> svn ls -depth infinity | xargs svn info
>
> This issue is that the first command takes 1 minute to run while the
> second command takes 6 seconds to run. I am runn
These operations do very different things. The first reads your working copy
to obtain a lot of details (unless you pass a revision; in that case it
looks at the repository)
The second asks the repository what files there are below the current
directory in the repository (using the revision of the
23 matches
Mail list logo
