On Fri, Feb 04, 2011 at 03:29:37AM +0200, Daniel Shahaf wrote:
> (test script attached --- hope it goes through)
>
> Stefan Sperling wrote on Wed, Feb 02, 2011 at 18:53:39 +0100:
> > I've made svn proplist issue per-directory queries in r1066541.
> > Reviews of this change are most welcome.
> > Also, if someone has a nice way of testing performance impacts of
> > this change it would be interesting to see the results.
> > I have not done any benchmarking myself yet.
> >
>
> Working copy of /tags/1.6.*, no local mods, r1066541:
> [[[
> ==> pristine-t1-1.out <==
> 233.55user 78.55system 5:12.08elapsed 100%CPU (0avgtext+0avgdata 32176maxresident)k
> 0inputs+0outputs (0major+6199minor)pagefaults 0swaps
>
> ==> pristine-t1-2.out <==
> 237.68user 79.22system 5:16.88elapsed 100%CPU (0avgtext+0avgdata 32176maxresident)k
> 0inputs+0outputs (0major+6200minor)pagefaults 0swaps
>
> ==> pristine-t1-3.out <==
> 232.96user 76.04system 5:08.98elapsed 100%CPU (0avgtext+0avgdata 32176maxresident)k
> 0inputs+0outputs (0major+6197minor)pagefaults 0swaps
> ]]]
>
> Ditto, r1066540:
> [[[
> ==> pristine-t2-1.out <==
> 253.41user 82.90system 5:36.27elapsed 100%CPU (0avgtext+0avgdata 30480maxresident)k
> 0inputs+0outputs (0major+6099minor)pagefaults 0swaps
>
> ==> pristine-t2-2.out <==
> 252.31user 82.52system 5:34.81elapsed 100%CPU (0avgtext+0avgdata 30480maxresident)k
> 0inputs+0outputs (0major+6090minor)pagefaults 0swaps
>
> ==> pristine-t2-3.out <==
> 234.95user 75.25system 5:10.15elapsed 100%CPU (0avgtext+0avgdata 30480maxresident)k
> 0inputs+0outputs (0major+6092minor)pagefaults 0swaps
> ]]]
>
> So, 5% more memory, but (excluding the t2-3 result) post-change is 7%
> faster than post-change.
Is this difference really significant?
> Ditto, with local prop mods on all *.c/*.py files:
> [[[
> ==> pset-Rpyc-t1-1.out <==
> 219.41user 67.76system 4:47.13elapsed 100%CPU (0avgtext+0avgdata 32192maxresident)k
> 0inputs+0outputs (0major+6200minor)pagefaults 0swaps
>
> ==> pset-Rpyc-t1-2.out <==
> 218.48user 65.74system 4:44.18elapsed 100%CPU (0avgtext+0avgdata 32192maxresident)k
> 0inputs+0outputs (0major+6205minor)pagefaults 0swaps
>
> ==> pset-Rpyc-t1-3.out <==
> 219.14user 67.83system 4:46.94elapsed 100%CPU (0avgtext+0avgdata 32192maxresident)k
> 0inputs+0outputs (0major+6197minor)pagefaults 0swaps
> ]]]
>
> Ditto, r1066540:
> [[[
> ==> pset-Rpyc-t2-1.out <==
> 217.34user 64.90system 4:42.20elapsed 100%CPU (0avgtext+0avgdata 30480maxresident)k
> 0inputs+0outputs (0major+6097minor)pagefaults 0swaps
>
> ==> pset-Rpyc-t2-2.out <==
> 215.01user 67.10system 4:42.08elapsed 100%CPU (0avgtext+0avgdata 30464maxresident)k
> 0inputs+0outputs (0major+6097minor)pagefaults 0swaps
>
> ==> pset-Rpyc-t2-3.out <==
> 212.82user 63.68system 4:36.46elapsed 100%CPU (0avgtext+0avgdata 30480maxresident)k
> 0inputs+0outputs (0major+6094minor)pagefaults 0swaps
> ]]]
>
> Pre-change is faster.
I'll look at profiler output. It has much better granularity.
It's possible that we still run queries elsewhere that affect the results.
We need to know whether the runtime overhead of sqlite queries has decreased.
Of course, with some usage patterns (e.g. working copies which contain only
directories, or disproportionally more directories than files),
we can expect little to no difference.
Stefan
Received on 2011-02-05 13:12:17 CET