You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andreas Krey <a....@gmx.de> on 2011/08/09 11:06:43 UTC
svn wc&repo performance
On Mon, 01 Aug 2011 07:39:59 +0000, Les Mikesell wrote:
...
> SQLlite has years of development and a good reputation for robust behavior.
I don't doubt that.
> I'd expect it to be hard to match its performance and reliability without
> an equally long development cycle.
We don't want an SQL server, we want an svn client.
A tool used must not only perform, but also be the proper tool.
> I don't quite understand the point of re-implementing something that is
> already developed on top of cross platform open source libraries.
Using SQL is a tradeoff between developer time and user time; any
implementation of SQL is obviously not as performant as a domain-specific
serialization can be. Given the large user base of svn, some more thought
in that direction may have been in order.
But I may be barking up the wrong tree. I built svn 1.7 and ran my
small 'second consecutive commit fails' test script with that. It's
not the local operations, but those that act on the repository (here:
file:///...) that take ridiculously long. Each commit and do-nothing
'svn up' takes about a second, for the five files involved. I've come
to expect such operations to be instantaneous.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: svn wc&repo performance
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 09 Aug 2011 12:12:17 +0000, Stefan Sperling wrote:
...
> export SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS=1
ITYM "...AMPS=yes". Then it's running faster (and not apparently corrupt)
indeed, and we're now closing up to git.
I'd like SVN_DO_CONTENT_CHECK_ON_EQUAL_TIMESTAMPS. ;-)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: svn wc&repo performance
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Aug 09, 2011 at 11:46:06AM +0200, Erik Huelsmann wrote:
> The fact that the 'svn up' takes about a second can't be blamed on SQL Lite
> or any other SQL engine. The Subversion client sleeps 1 second to make sure
> that it's able to detect changes to files: it does timestamp checks and
> returning immediately would allow a short timeframe where modifying the file
> would not result in a new timestamp (namely, modifications within the same
> second, such as the use by scripts).
Good point.
Andreas, to confirm that the sleep for timestamps affects your
measurements you can put this on top of your script:
export SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS=1
Re: svn wc&repo performance
Posted by Erik Huelsmann <eh...@gmail.com>.
Hi Andreas,
On Tue, Aug 9, 2011 at 11:06 AM, Andreas Krey <a....@gmx.de> wrote:
> On Mon, 01 Aug 2011 07:39:59 +0000, Les Mikesell wrote:
> ...
> > SQLlite has years of development and a good reputation for robust
> behavior.
>
> I don't doubt that.
>
> > I'd expect it to be hard to match its performance and reliability without
> > an equally long development cycle.
>
> We don't want an SQL server, we want an svn client.
>
> A tool used must not only perform, but also be the proper tool.
>
> > I don't quite understand the point of re-implementing something that is
> > already developed on top of cross platform open source libraries.
>
> Using SQL is a tradeoff between developer time and user time; any
> implementation of SQL is obviously not as performant as a domain-specific
> serialization can be. Given the large user base of svn, some more thought
> in that direction may have been in order.
>
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
> small 'second consecutive commit fails' test script with that. It's
> not the local operations, but those that act on the repository (here:
> file:///...) that take ridiculously long. Each commit and do-nothing
> 'svn up' takes about a second, for the five files involved. I've come
> to expect such operations to be instantaneous.
>
>
The fact that the 'svn up' takes about a second can't be blamed on SQL Lite
or any other SQL engine. The Subversion client sleeps 1 second to make sure
that it's able to detect changes to files: it does timestamp checks and
returning immediately would allow a short timeframe where modifying the file
would not result in a new timestamp (namely, modifications within the same
second, such as the use by scripts).
Bye,
Erik.
Re: svn wc&repo performance
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 09 Aug 2011 11:38:41 +0000, Stefan Sperling wrote:
...
> Which script are you referring to? Can you post it or provide a link?
This one:
set -xe
rm -rf repo wc
time svnadmin create repo
time svn checkout file:///`pwd`/repo wc
cd wc
mkdir D
touch A D/B D/C E
# svn add . # <- That nuisance 'already under control'...
time svn add A D E
time svn commit -m 'initial'
time svn up
time svn up
date >D/B
date >A
time svn propset blub blah .
#(cd D && svn commit . -m green)
time svn commit D -m green
time svn commit . -m blau
> What platform are you running your test on?
Macbook Pro, not that new. The times are pretty similar on a Sun, as
well as on a linux box. (Also across svn versions, from 1.5.5 to 1.7)
Output on the latter:
===========
+ rm -rf repo wc
+ svnadmin create repo
real 0m0.577s
user 0m0.004s
sys 0m0.008s
++ pwd
+ svn checkout file:////home/krey/svnt/repo wc
Checked out revision 0.
real 0m0.672s
user 0m0.008s
sys 0m0.004s
+ cd wc
+ mkdir D
+ touch A D/B D/C E
+ svn add A D E
A A
A D
A D/B
A D/C
A E
real 0m0.032s
user 0m0.004s
sys 0m0.004s
+ svn commit -m initial
Adding A
Adding D
Adding D/B
Adding D/C
Adding E
Transmitting file data ....
Committed revision 1.
real 0m0.931s
user 0m0.016s
sys 0m0.012s
+ svn up
At revision 1.
real 0m1.000s
user 0m0.000s
sys 0m0.008s
+ svn up
At revision 1.
real 0m1.002s
user 0m0.000s
sys 0m0.008s
+ date
+ date
+ svn propset blub blah .
property 'blub' set on '.'
real 0m0.016s
user 0m0.008s
sys 0m0.004s
+ svn commit D -m green
Sending D/B
Transmitting file data .
Committed revision 2.
real 0m0.973s
user 0m0.004s
sys 0m0.008s
+ svn commit . -m blau
Sending .
svn: Commit failed (details follow):
svn: Directory '/' is out of date
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: svn wc&repo performance
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Aug 09, 2011 at 11:06:43AM +0200, Andreas Krey wrote:
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
> small 'second consecutive commit fails' test script with that. It's
> not the local operations, but those that act on the repository (here:
> file:///...) that take ridiculously long. Each commit and do-nothing
> 'svn up' takes about a second, for the five files involved. I've come
> to expect such operations to be instantaneous.
Which script are you referring to? Can you post it or provide a link?
What platform are you running your test on?
AW: svn wc&repo performance
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Andreas,
Andreas Krey [mailto:a.krey@gmx.de]
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
small
> 'second consecutive commit fails' test script with that. It's not the
> local operations, but those that act on the repository (here:
> file:///...) that take ridiculously long. Each commit and do-nothing
'svn
> up' takes about a second, for the five files involved. I've come to
expect
> such operations to be instantaneous.
We had similar timing issues when accessing repositories via SharpSVN -
but it happened on svn:// and http:// issues - each remote operation
expected to take X ms did take (1s + X ms).
In our case it was an IPv6 Problem: The server was only reachable on
IPv4, but the host name of that server (localhost) did resolve to both
an IPv6 and IPv4 address. The Windows 7 IP stack now seems to try an
IPv6 connect, and if that fails, waits 1 second until retrying via IPv4.
I don't think that both problems are related (especially as that
happened to us using Svn 1.6), but the effect seems to be the same. :-)
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915