On Tue, Feb 8, 2011 at 7:27 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Feb 08, 2011 at 05:13:50PM +0000, Hyrum K Wright wrote:
>> On Tue, Feb 8, 2011 at 4:15 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> > On Tue, Feb 08, 2011 at 04:34:52PM +0100, Bert Huijben wrote:
>> >> There is nobody actively working on status and there are no open
>> >> issues on status to block branching...
>> > There's the general wc-ng performance issue (but I don't think it has
>> > an issue number attached to it right now).
>> If performance of 'status' is a release blocker, we need to document
>> and treat it as such.
>> Also instead of nebulous handwaving about "performance is bad", it
>> would be nice to have actually datasets and actual numbers. †We have a
>> VM at the ASF which could be used for hosting a set of benchmarking
>> data; we just need somebody to put together the data and write the
>> scripts which run the benchmarks.
> I'll ask Neels about running his set of performance tests on the VM
> (see http://svn.haxx.se/dev/archive-2010-09/0526.shtml).
> I know he's not following dev@ closely ATM, but maybe he'll see this one
> anyway cause his name is in it -- but I can more easily catch his attention
> by waving across the yard from my kitchen window :)
>> [And yes, I realize that I bring up all these points without actually
>> I've been pleading with folks I know who use large working copies to
>> do some testing, but I haven't gotten any feedback from them, partly
>> because following up with everybody is kind of a pain, and partly
>> because there aren't any packaged binaries for people to test. †Would
>> it be worth it to have a beta-testers_at_subversion.apache.org list,
>> which we could use to communicate with the bleeding-edge folks in
>> release situations like this?
>> It shouldn't be difficult to create a large working copy ('svn co
>> ^/subversion') and use that for testing, but getting more insight than
>> just our own dataset would be very nice.
> We'll find some way to test with large WCs, no doubt.
> In any case, I think that changing our code to use sqlite more
> effectively, in the manner suggested by Branko, is the way to go.
> The approach would also allow us to address Stefan KŁng's requests
> in http://svn.haxx.se/dev/archive-2011-02/0104.shtml for APIs that
> quickly pull various information from the DB.
All good ideas.
One of my greater concerns is that we don't have a concrete answer to
"we'll release when ____" for the performance question. What is good
enough? Which operations? How much better than 1.6.x? Having a
concrete answer, and not just "when it feels good" will give us some
objective criteria, and prevent the "one more bugfix" delays we've had
in the past. We're fooling ourselves if we think we're going to nail
all the performance issues before the 1.7.0 release.
The silver lining here is that most performance problems are *not*
going to have compat implications, so they can easily be backported in
future patch releases.
Received on 2011-02-08 20:40:43 CET