We did a pretty good job with improving Chandler performance in 0.6. We
didn't reach all of our goals, but we got it to usable. And frankly, I
was positively surprised how far we got. So good job!

Since there is still work to do we should think about the performance
goals for 0.7.

I don't think we want to regress from the numbers we have achieved so
far. The exception may be a new compelling feature we want, but even
then, we should work hard to avoid performance regressions.

There are a couple of approaches we could take. One is to concentrate on
the cases that are furthest from our 0.6 goals. The other is to take a
broad look and work on all the cases that are not yet under the ideal
limits. In the first case our numeric goals would remain unchanged. In
the second case we would set new, tighter goals for the cases that did
make it under acceptable limits but are not yet under ideal limits.
Personally I am in favor of the latter. I have some initial suggestions
here:
http://wiki.osafoundation.org/bin/view/Journal/ZeroSevenPerfGoals20051204


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.

-- 
  Heikki Toivonen

Attachment: signature.asc
Description: OpenPGP digital signature

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Reply via email to