[Dev] 0.7 perf goals

[Alec Flett]

Philippe Bossut wrote:
> Katie Capps Parlante wrote:
>
>> This approach seems pretty reasonable for Mozilla (or Safari, which I 
>> hear has a similar system), where the intense focus is on a 
>> particular well-known use case. In our case, we're continuing to 
>> tweak the functionality and even change the formulation of the use 
>> cases that we measure. I think it would be overly constraining at 
>> this point to have a formal "back all regressions out" policy. 
>
> Agree. The "back out regressions" policy was also used on MacIE (and 
> MSN for OS X). It was extremelly efficient but, as Katie said, was 
> focusing on well-known use case and a particularly stable feature set. 
I think we just had our first "use case" of performance regressions on 
the trunk... I checked in a big change to calendar yesterday which 
unfortunately had the rather unexpected side effect of causing new event 
creation to be slow (again).. heikki noticed and filed a bug - thank 
goodness because I didn't even realize I slowed stuff down (mostly 
because I checked in at the end of the day... again, a historical graph 
would have helped me help myself here)

But since we're at the beginning of a milestone, and there are other 
architecture changes coming down the pipe in the next few weeks, I think 
it makes sense to hold off on trying to optimize that case again, until 
we've sorted out some of the other architecture stuff, like the hints 
bit I keep talking about.

[And a further note about bug management: Sure, I have one more bug 
against me, but it will be prioritized over time along with all the 
others.. just because heikki filed it against me doesn't mean I need to 
interrupt everything I'm doing to decide how to handle this bug]

Fortunately, we have a good baseline established in 0.6, and a bug filed 
against me, to 'keep me honest' about actually fixing the regression, 
one way or the other, for the next release.

Alec



> I think that enforcing this policy on Chandler (or Cosmo for that 
> matter) right now would lead to Premature Optimization issues for any 
> significant feature we add.
>
> Note that we (MacIE) also used a historized graph (as recommended by 
> Alec and others) and it's only when we got that implemented that 
> people (devs) could make sense of the data and we started to see 
> significant perf improvments.
>
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev