[Dev] 0.7 perf goals

[Andi Vajda]

> There's also a question of policy. Do we want to mandate a strict policy
> of not allowing performance regressions (regressions backed out, no
> questions asked), or do we consider each regression on a case by case
> basis? The danger with the second approach is that if we leave the
> regression in, and other code starts piling on top of those changes, it
> can be hard to back out even if we wanted to. Personally I am slightly
> in favor of a strict policy, but the other approach might also work well
> if we have just a few regressions.
>
> Mozilla has long maintained a very strict policy where regressions are
> simply backed out. If you really wanted your fix/feature in, there were
> two options: make a change such that performance does not regress, or
> convince everyone that your change is so important it trumps performance.

I think it's still too early in the Chandler release cycle to run the project 
as if it were Mozilla. Anything that makes development actually harder, that 
introduces drag on getting features out is - at this time - not worth the 
benefits of avoiding performance regressions.

Even though we've never been as good about performance tracking and fixing as 
in the 0.6 release, there is still room for lots of improvement. For instance, 
most of the performance tests used in 0.6 are too far from end user 'reality' 
to make regressions an auto-backed out showstopper. A goal for 0.7 in the 
performance tracking area should be to have more tests reflecting real 
end-user situations.

Andi..