wc_db API discussion

[Ivan Zhakov]

I think we have to get this work done soon.  We cannot release with
performance like it is.  How do we define the scope of the work that
needs to be done so that we can divide and conquer and get these
changes in place?

It sounds like we should codify what our performance targets are.
Is it acceptable if 1.7 is as fast as 1.6?  Should it be faster?

I think 1.7 should be faster on large working copies. I've got many
complaints from users when svn status takes minutes using svn 1.6.x.
And they're asking when svn 1.7 will be released with improvements of
svn status performance.

Could we accept a slowdown for 1.7 as long as we know how we can get
it on par (or faster) for 1.8?
What are the operations (and test cases?) that are important to us?  -- justin

IMHO: svn status and svn update.

[Mark Phippard]

On Sat, Mar 12, 2011 at 12:49 PM, Justin Erenkrantz

I think we have to get this work done soon.  We cannot release with
performance like it is.  How do we define the scope of the work that
needs to be done so that we can divide and conquer and get these
changes in place?

It sounds like we should codify what our performance targets are.
What are the operations (and test cases?) that are important to us?  -- justin

I agree that we will have to codify this.

Is it acceptable if 1.7 is as fast as 1.6?  Should it be faster?
Could we accept a slowdown for 1.7 as long as we know how we can get
it on par (or faster) for 1.8?

I think it should be faster overall. Like Ivan, I think status and
update on large working copies are areas where I would like to see
show significant improvements.

I can live with some operations being comparable to 1.6. I do not
think we can accept any major regressions in performance. It looks
like checkout is currently a major regression (but we should try to
codify that). It definitely looks like NFS mounted working copies is
a major regression. I do not think we can ship without getting those
back to 1.6 levels.

CPU usage is also way higher which might yield regressions that are
harder for us to quantify with benchmarks. I think we can only keep
an eye on that and hope it comes down as we make improvements to
overall performance.

[Branko Čibej]

Post by Mark Phippard
On Sat, Mar 12, 2011 at 12:49 PM, Justin Erenkrantz

I think we have to get this work done soon. We cannot release with
performance like it is. How do we define the scope of the work that
needs to be done so that we can divide and conquer and get these
changes in place?

It sounds like we should codify what our performance targets are.
What are the operations (and test cases?) that are important to us? -- justin

I agree that we will have to codify this.

Is it acceptable if 1.7 is as fast as 1.6? Should it be faster?
Could we accept a slowdown for 1.7 as long as we know how we can get
it on par (or faster) for 1.8?

I think it should be faster overall. Like Ivan, I think status and
update on large working copies are areas where I would like to see
show significant improvements.
I can live with some operations being comparable to 1.6. I do not
think we can accept any major regressions in performance. It looks
like checkout is currently a major regression (but we should try to
codify that). It definitely looks like NFS mounted working copies is
a major regression. I do not think we can ship without getting those
back to 1.6 levels.
CPU usage is also way higher which might yield regressions that are
harder for us to quantify with benchmarks. I think we can only keep
an eye on that and hope it comes down as we make improvements to
overall performance.

I have a feeling that all of these concerns -- CPU usage, speed in
general and especially speed over NFS -- will be solved by the "simple"
expedient of issuing a lot less transactions per operation. By a lot
less, I mean not proportional to WC size.

-- Brane

[Philip Martin]

Post by Mark Phippard
I think it should be faster overall. Like Ivan, I think status and
update on large working copies are areas where I would like to see
show significant improvements.
I can live with some operations being comparable to 1.6. I do not
think we can accept any major regressions in performance. It looks
like checkout is currently a major regression (but we should try to
codify that). It definitely looks like NFS mounted working copies is
a major regression. I do not think we can ship without getting those
back to 1.6 levels.

Subversion has always been slower on network disks and 1.7 has made the
problem worse:

Checkout to local disk:

1.6: 8.5s
1.7: 8.5s

Checkout to NFS disk:

1.6: 1min 59s
1.7: 6min 49s

Update with no changes on local disk:

1.6: 0.2s
1.7: 1.3s

Update with no changes on NFS disk:

1.6: 2s
1.7: 50s

Local checkout looks OK, but that is probably because the database
operations are dominated by network/pristine/working operations.

My experience with status:
http://svn.haxx.se/dev/archive-2010-10/0350.shtml
leads me to believe that we can only get acceptable performance by
reducing the number of queries. I have no idea how we do that for
checkout/update.

[Philip Martin]

Post by Philip Martin
1.6: 2s
1.7: 50s

With the recent bump-post-update changes that 50s has become 23s.