[darcs-users] performance regression in check/repair
kowey at darcs.net
Sat Jan 16 15:44:04 UTC 2010
On Sat, Jan 16, 2010 at 00:32:07 -0800, Jason Dagit wrote:
> I hope we're not glossing over anything here. Is there a bug report for the
> check failure in the beta yet? It looks like 2.2 and 2.3 were able to check
> that repo, so why should we ship 2.4 if it fails to check it?
I'll bet that the check failure is just a consequence of the performance
regression noted in <http://bugs.darcs.net/issue1731>, but if anybody
wants to offer evidence to the contrary, please do file a report.
> > > || darcs-2.2.0 | darcs-2.2.1 | darcs-2.3.1
> > | darcs
> > Yeah, we should adopt a convention of what order we put these in.
> > I guess the left-to-right order, while less convenient is the most
> > intuitive. I don't really mind either way; let's just pick one!
> Why is it less convenient?
I won't answer that now because it will confuse the issue (and also
because I think we should go with it even if it's slightly less
> Also, since the columns are labeled why is it important to pick one?
It makes life easier for people reading the tables if they don't have to
think about it!
Also it makes things like comparing different versions of the same table
easier. Consider if I want to compile results by you and Max into a
single email. Much easier if folks could just scan down the list.
The general principle here is that writers should be willing to accept a
greater burden than their readers, because there is generally 1 writer
to many readers. So if we take the time out to work out the best order
(eg. by imposing a convention, or by having darcs-benchmark do it for
us), that bit of effort pays off N-fold for the number of readers.
> I'm someone who is unlikely to remember what order I used, or others
> used in the past, so to me the labels are significantly more valuable
> than a convention.
Then let's go with the "intuitive" left-to-right order (older version
first, 1 < 2 < 3). It's more robust because it's more likely to be
what comes naturally anyway.
OK, let me stress that this doesn't *really* matter. Nobody is going to
make a big stink about it either way; it was just an innocent offside
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
More information about the darcs-users