1.7 performance requirements for release

[Blair Zajac <bl...@orcaware.com>]

Do we have any performance requirements for the 1.7 release?  If a  
particular operation, say checkout, is X times slower than the 1.6  
operation, we consider it a performance regression?  I feel like  
checkout, with a 2x performance drop which I saw in recent performance  
tests, is a large regression:

http://svn.haxx.se/dev/archive-2010-12/0161.shtml

Do we need to be faster than 1.6 to do a release?  Do we want to say,  
all operations are at least X% faster?  It's a much more powerful  
statement than saying, some operations are faster and some are the  
same speed.

I don't feel that strongly about upgrade taking forever, since many  
people can do a fresh checkout, but I could see this being an issue  
for people with uncommitted changes in their working copy or  
changelists.

Blair

Re: 1.7 performance requirements for release

[Mike Dixon <mi...@denovosoftware.com>]

On 12/9/2010 5:27 AM, Bolstridge, Andrew wrote:
> The one-off upgrade isn't a concern. Its once-only after all.

Indeed, it's once-only, but it's going to be the first impression many
users get of 1.7. I'm also not sure that admins of large repositories
particularly want all their clients to re-checkout everything.

I realize it's not as important as, say, update, but I think it'd be a
mistake to write off upgrade without trying to optimize it at all.

-Mike

RE: 1.7 performance requirements for release

["Bolstridge, Andrew" <an...@intergraph.com>]

> -----Original Message-----
> From: Blair Zajac [mailto:blair@orcaware.com]
> Sent: 09 December 2010 00:45
> To: dev@subversion.apache.org
> Subject: 1.7 performance requirements for release
> 
[snip]
> 
> Do we need to be faster than 1.6 to do a release?  Do we want to say,
all
> operations are at least X% faster?  It's a much more powerful
statement than
> saying, some operations are faster and some are the same speed.

I'd say all (common) operations need to be faster, or it might as well
just use the old codebase. 

The problem is that, even if update was faster but checkout was slower
there would be many people who use checkout a lot more than update and
would complain, so we can't make assumptions about which operation is
more important than another. The best that can be done is to group a
subset of operations that is commonly used and make sure they are all
faster. 

> 
> I don't feel that strongly about upgrade taking forever, since many
people
> can do a fresh checkout, but I could see this being an issue for
people with
> uncommitted changes in their working copy or changelists.
> 

The one-off upgrade isn't a concern. Its once-only after all. Anyone
with uncommitted changes in their WC can either commit them, or copy
them to a different directory and then copy them back over a freshly
checked-out directory. If that's what I had to do with a new version
(that jumped from 1.6 to 1.7) I wouldn't be bothered at all.