You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2011/04/11 14:49:01 UTC
Performance of checkout/update going in the wrong direction
Just an fyi ...
I am not sure what has caused it as all I have seen is a number of
commits from Bert that said they were eliminating SQLite queries, but
the performance test results have been showing the times for checkout
and update to be getting slower. For example on the relatively
lightweight test that uses our Subversion tree the time for checkout
and update on Windows has gone like this:
Checkout Update
1.7.0 r1085344 0:23.432 0:23.681
1.7.0 r1088721 0:33.175 0:23.681
1.7.0 r1089890 0:42.526 0:35.396
1.7.0 r1085031 0:24.164 0:20.039
1.7.0 r1088319 0:18.782 0:14.172
1.7.0 r1090787 0:27.627 0:25.951
The first three are from my machine, the second three are from Stefan King's.
Given the overlap in the builds we used I would look at what happened
between -r1088721:1088319
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Performance of checkout/update going in the wrong direction
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Apr 11, 2011 at 8:49 AM, Mark Phippard <ma...@gmail.com> wrote:
> Just an fyi ...
>
> I am not sure what has caused it as all I have seen is a number of
> commits from Bert that said they were eliminating SQLite queries, but
> the performance test results have been showing the times for checkout
> and update to be getting slower. For example on the relatively
> lightweight test that uses our Subversion tree the time for checkout
> and update on Windows has gone like this:
>
> Checkout Update
> 1.7.0 r1085344 0:23.432 0:23.681
> 1.7.0 r1088721 0:33.175 0:23.681
> 1.7.0 r1089890 0:42.526 0:35.396
>
> 1.7.0 r1085031 0:24.164 0:20.039
> 1.7.0 r1088319 0:18.782 0:14.172
> 1.7.0 r1090787 0:27.627 0:25.951
>
> The first three are from my machine, the second three are from Stefan King's.
>
> Given the overlap in the builds we used I would look at what happened
> between -r1088721:1088319
I would say to just ignore this for now. Even if I go back to
r1085344 I am not getting that time anymore, so maybe something is
happening on my system (or the growth in revision in my test
repository) explains the problem?
I also realized that since this is the first test run the OS caching
of the repository files matters. Just running the tests twice reduces
the times on the checkout. I am seeing maybe a 2-second difference on
the checkout right now. Bert thinks he knows why and that it is
temporary.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/