[svnbench] Failed to build Revision: 1449572.

[ne...@apache.org]

Failed to build Revision: 1449572.

Re: [svnbench] Failed to build Revision: 1449572.

[Neels Hofmeyr <ne...@elego.de>]

On Wed, 27 Feb 2013 09:17:36 -0800
Ben Reser <be...@reser.org> wrote:

> On Wed, Feb 27, 2013 at 8:53 AM, Neels Hofmeyr <ne...@elego.de> wrote:
> > (Simply uncommenting now would change the test case and could make
> > the new runs too different from the old runs, decreasing quality of
> > comparison. So it needs some checking and decisions too.)
> 
> Maybe duplicate the copy test with a different name e.g. copy+wc and
> then you'll start getting comparisons with that without impacting the
> existing comparisons.

The benchmark initially was just a quick test for me, trying to write
down concrete 1.7.0 numbers in a magazine article. So I used a pseudo
random sequence that decides which modification to make. Just so I
didn't have to conjure up hundreds of modifications manually. Later on,
I simply clamped the initial random seed to get identical runs.

So if something else happens somewhere along the way, all the remaining
actions are impacted, simply because the random sequence plays out
differently.

I could of course simply *append* actions, now that I think of
it :) -- that should be quick and easy, in fact.

But I would anyway like to further reduce the number of propset/propget
benchmarks, because they just unnecessarily blow up the database
storage. That's why I'm considering a "complete" review anyway...

~Neels

Re: [svnbench] Failed to build Revision: 1449572.

[Ben Reser <be...@reser.org>]

On Wed, Feb 27, 2013 at 8:53 AM, Neels Hofmeyr <ne...@elego.de> wrote:
> (Simply uncommenting now would change the test case and could make the
> new runs too different from the old runs, decreasing quality of
> comparison. So it needs some checking and decisions too.)

Maybe duplicate the copy test with a different name e.g. copy+wc and
then you'll start getting comparisons with that without impacting the
existing comparisons.

Re: [svnbench] Failed to build Revision: 1449572.

[Neels Hofmeyr <ne...@elego.de>]

On Wed, 27 Feb 2013 12:42:53 +0000
Philip Martin <ph...@wandisco.com> wrote:

> Daniel Shahaf <d....@daniel.shahaf.name> writes:
> 
> > Philip Martin wrote on Wed, Feb 27, 2013 at 12:09:55 +0000:
> >> Neels Hofmeyr <ne...@elego.de> writes:
> >> 
> >> > On Mon, 25 Feb 2013 18:04:05 +0200
> >> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >> >
> >> >> /usr/local/serf-current was serf-1.2.x-r1707.  I've installed
> >> >> 1.2.0 and updated the self-current symlink accordingly.
> >> >
> >> > No, the build has its own source trees. You know, it's one of
> >> > those "complete" builds that you do like so much ;)
> >> 
> >> Which version of SQLite is used?
> >
> > 3.7.12.1

Yep, this ball in particular:
http://www.sqlite.org/sqlite-autoconf-3071201.tar.gz

> I was trying to see if that would explain why the charts show copy as
> a regression.  The charts show copy performance fluctuating wildly
> however I think that may be a false alarm.  Looking at the script the
> only copy that I can see is an URL-to-URL copy; a copy like that has
> nothing to do with working copy performance and may well be dominated
> by program startup costs.

Have you looked at the right-hand-side column? That shows the absolute
times in realtime. If the absolute times are fractions of a second I
wouldn't even consider the left-hand-side showing percentages. 'copy'
is one of those operations that are done very quickly while modifying
the file system, so they are subject to unproportional OS overhead...

If the benchmark has only url-to-url copies, that would be stupid. AFAIR
I explicitly had wc-wc copies to see the improvement in WC overhead by
having the pristines store...

Hmm, I took a look, and I indeed have a WC-WC copy -- but it's commented
out :/

_mod_funcs = (_mod, _add, _propmod, _propadd, )#_copy,) # _move, _del

Can't remember why I did that. I think I did have a reason though.
I'll take a look some time or other.

(Simply uncommenting now would change the test case and could make the
new runs too different from the old runs, decreasing quality of
comparison. So it needs some checking and decisions too.)

Thanks for spotting,
~Neels

Re: [svnbench] Failed to build Revision: 1449572.

[Philip Martin <ph...@wandisco.com>]

Daniel Shahaf <d....@daniel.shahaf.name> writes:

> Philip Martin wrote on Wed, Feb 27, 2013 at 12:09:55 +0000:
>> Neels Hofmeyr <ne...@elego.de> writes:
>> 
>> > On Mon, 25 Feb 2013 18:04:05 +0200
>> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> >
>> >> /usr/local/serf-current was serf-1.2.x-r1707.  I've installed 1.2.0
>> >> and updated the self-current symlink accordingly.
>> >
>> > No, the build has its own source trees. You know, it's one of those
>> > "complete" builds that you do like so much ;)
>> 
>> Which version of SQLite is used?
>
> 3.7.12.1

I was trying to see if that would explain why the charts show copy as a
regression.  The charts show copy performance fluctuating wildly however
I think that may be a false alarm.  Looking at the script the only copy
that I can see is an URL-to-URL copy; a copy like that has nothing to do
with working copy performance and may well be dominated by program
startup costs.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: [svnbench] Failed to build Revision: 1449572.

[Daniel Shahaf <d....@daniel.shahaf.name>]

Philip Martin wrote on Wed, Feb 27, 2013 at 12:09:55 +0000:
> Neels Hofmeyr <ne...@elego.de> writes:
> 
> > On Mon, 25 Feb 2013 18:04:05 +0200
> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >
> >> /usr/local/serf-current was serf-1.2.x-r1707.  I've installed 1.2.0
> >> and updated the self-current symlink accordingly.
> >
> > No, the build has its own source trees. You know, it's one of those
> > "complete" builds that you do like so much ;)
> 
> Which version of SQLite is used?

3.7.12.1

Re: [svnbench] Failed to build Revision: 1449572.

[Philip Martin <ph...@wandisco.com>]

Neels Hofmeyr <ne...@elego.de> writes:

> On Mon, 25 Feb 2013 18:04:05 +0200
> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
>> /usr/local/serf-current was serf-1.2.x-r1707.  I've installed 1.2.0
>> and updated the self-current symlink accordingly.
>
> No, the build has its own source trees. You know, it's one of those
> "complete" builds that you do like so much ;)

Which version of SQLite is used?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: [svnbench] Failed to build Revision: 1449572.

[Neels Hofmeyr <ne...@elego.de>]

On Mon, 25 Feb 2013 18:04:05 +0200
Daniel Shahaf <d....@daniel.shahaf.name> wrote:

> /usr/local/serf-current was serf-1.2.x-r1707.  I've installed 1.2.0
> and updated the self-current symlink accordingly.

No, the build has its own source trees. You know, it's one of those
"complete" builds that you do like so much ;)

~Neels

Re: [svnbench] Failed to build Revision: 1449572.

[Daniel Shahaf <d....@daniel.shahaf.name>]

Neels Hofmeyr wrote on Mon, Feb 25, 2013 at 14:20:11 +0100:
> On Mon, 25 Feb 2013 00:21:09 +0000
> neels@apache.org wrote:
> 
> > Failed to build Revision: 1449572.
> 
> The failure was that trunk now needs serf 1.2.0, while the benchmark
> config was still using 1.1.0. I updated the default serf version in the
> build scripts and have just kicked off another run.
> 
> (1.7.0 will still build with serf-1.1.0, trunk with 1.2.0.)

/usr/local/serf-current was serf-1.2.x-r1707.  I've installed 1.2.0 and
updated the self-current symlink accordingly.

(feel free to do that yourself next time :))

Re: [svnbench] Failed to build Revision: 1449572.

[Neels Hofmeyr <ne...@elego.de>]

On Mon, 25 Feb 2013 00:21:09 +0000
neels@apache.org wrote:

> Failed to build Revision: 1449572.

The failure was that trunk now needs serf 1.2.0, while the benchmark
config was still using 1.1.0. I updated the default serf version in the
build scripts and have just kicked off another run.

(1.7.0 will still build with serf-1.1.0, trunk with 1.2.0.)

~Neels