On Sat, Feb 5, 2011 at 9:37 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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
I should've added one more test, to put things in perspective :-),
namely the test with r1039808 (the per-wc query version):
$ time svn proplist -R . >/dev/null
real 0m0.328s
user 0m0.015s
sys 0m0.031s
(but, as you probably already know, this execution is not cancellable,
which is pretty annoying :-), especially when I forget to redirect to
/dev/null, but let it write on the console).
Cheers,
--
Johan
Received on 2011-02-05 21:56:02 CET