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

Re: SQLite and callbacks

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sat, 5 Feb 2011 21:37:57 +0100

On Sat, Feb 5, 2011 at 7:14 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sat, Feb 05, 2011 at 06:47:35PM +0100, Branko Čibej wrote:
>> I would not worry about existing clients -- simply mark the existing
>> APIs as deprecated, but keep them and do not attempt to improve their
>> performance.
>
> Neglecting performance of backwards compat code is an interesting idea.
> It allows us to focus on the new APIs first and foremost.
>
> The existing APIs will continue to work using the node walker and issue
> queries per node as they do now. We could consider optimising them later,
> before or after 1.7 release. The required changes are mostly mechanical.

I agree with most of what's been said here. I think it would be a pity
to use WC-NG in a way that provides far from optimal performance.

FWIW, I just did a quick run of your per-directory proplist query vs.
the per-node version, on my Windows XP platform, to have another data
point. The performance improvement is significant, but not
earth-shattering (around 20%).

Just tested with a freshly checked out working copy of svn trunk:

1) Per-node queries (r1066540). Looking at the third run, to make sure
everything is hot in cache:

$ time svn proplist -R . >/dev/null

real 0m1.532s
user 0m0.015s
sys 0m0.015s

2) Per-dir queries (r1066541). Looking at the third run, to make sure
everything is hot in cache:

$ time svn proplist -R . >/dev/null

real 0m1.218s
user 0m0.015s
sys 0m0.031s

3) For comparison, I also tested with SlikSVN 1.6.13. This is still
more than twice as fast:

$ time svn proplist -R . >/dev/null

real 0m0.578s
user 0m0.015s
sys 0m0.046s

Cheers,

-- 
Johan
Received on 2011-02-05 21:38:56 CET

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.