RE: Really lousy performance with svn info --depth infinity

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

real 0m2.548s
user 0m0.350s
sys 0m0.142s

1.7.0-rc2

-> time svn info --depth infinity > /dev/null

real 6m51.036s
user 0m13.947s
sys 0m10.880s

-Mike

-----Original Message-----
From: Philip Martin [mailto:philip.martin_at_wandisco.com]
Sent: Thursday, September 01, 2011 10:26 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: d.s_at_daniel.shahaf.name; dev_at_subversion.apache.org
Subject: Re: Really lousy performance with svn info --depth infinity

<michael_rytting_at_agilent.com> 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
>
> real 0m0.225s
> user 0m0.204s
> sys 0m0.016s
>
> 1.7.0-rc2
>
> -> time svn info --depth infinity > /dev/null
>
> real 0m7.741s
> user 0m6.571s
> sys 0m1.155s

The recursive "svn info" still does multiple sqlite transactions per-node, that probably explains why it is slower than 1.6. It's doesn't really explain why the single recursive call is slower than multiple non-recursive calls, since each non-recursive call also makes several sqlite transactions.

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?

--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com