On Tue, Feb 08, 2011 at 07:40:03PM +0000, Hyrum K Wright wrote:
> 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.
I would say the minimum is as good as 1.6. And if we're doing this
smartly it's likely that trying to get trunk up to par with 1.6 will
boost performance beyond 1.6.x capabilities anyway.
> 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.
Sure, we can always try to make it faster.
What we need to avoid, though, is making the 1.7 release a disappointment
from a performance point of view. If 1.7 is any slower than the, by current
standards, glacial 1.6, it would just be a waste of a release.
It's likely that quite a few of our users would jump ship even if we
promised to follow up with performance improvements in 1.8.
git and hg have less development baggage to carry so they can release
improvements much quicker. And they're already much faster than Subversion 1.6
is in general, even in cases where svn only does local i/o.
Talking to the server over the network will always be slower than talking
to a repository on local disk, but there's no good excuse to be much slower
than alternative systems in other cases...
Received on 2011-02-08 21:00:18 CET