[Dev] Performance update

[Andi Vajda]

My mistake, I thought scrolling meant moving week to week. Apologies.

Andi..

On Wed, 2 Nov 2005, Katie Capps Parlante wrote:

> 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
>
>