[Dev] Performance update

[Katie Capps Parlante]

To be clear, by "scrolling" we mean the scrollbar in the calendar view, 
not moving from week to week. I don't know that we have an automated 
test for moving from week to week (or day to day). If this is indeed 
very slow, we should (I'll go figure that out).

If I understand correctly, the calendar Heikki has been using is the one 
found at tools/QATestScripts/DataFiles/Generated3000.ics. This is the 
calendar that the scripts have been measuring.

My reasoning for wanting to close this:
+ We're very close to the target (picked somewhat arbitrarily by me, 
with less confidence than with the other targets)
+ When I test it out myself, it meets my subjective test of acceptable 
(not quite ideal though)
+ When I test it out on family members, they say they find it acceptable
+ Mitch has not had problems with scrolling when dogfooding with his 
calendar.

As Alec pointed out in the bug, scrolling performance is currently 
proportional to items on the screen, not the overall size of the 
calendar (unlike other use cases).

Cheers,
Katie

Andi Vajda wrote:
> 
> Scrolling the 3000 event calendar Heikki has been using is still *very* 
> slow because of bug 4477. I'd make that one a blocker of this bug.
> 
> Andi..
> 
> On Wed, 2 Nov 2005, Katie Capps Parlante wrote:
> 
>> Most excellent.
>>
>> I agree, we've hit "acceptable" for scrolling -- we should close this 
>> bug and move on to higer priority bugs.
>>
>> Cheers,
>> Katie
>>
>> Alec Flett wrote:
>>
>>> Heikki Toivonen wrote:
>>>
>>>> Scrolling the 3000 event
>>>> calendar is under acceptable limits on Windows and Linux, and really
>>>> close to the limit on Mac (might go under with alecf's latest changes -
>>>> we'll see).
>>>>
>>>>
>>> It did - we dropped another 10%! It says "0.10s" on the performance 
>>> page, though its outlined in orange - I assume that means its really 
>>> something like 0.104s? Or maybe, since python's floating point math 
>>> can be pretty nuts, its more like 0.10392893598724s. Can we just 
>>> round, rather than truncate when doing our coloring? :)
>>>
>>> I'm reaching a point with the calendar where I'm going to need to do 
>>> some serious rearchitecture to get any more performance gains - I 
>>> mean I can eek out 1-3% here and there, but anything significant (8% 
>>> or higher, I'd say) is going to require changes that are too risky 
>>> for 0.6.
>>>
>>> Alec
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev