[Chandler-dev] Week changing performance

[Jeffrey Harris]

Hi Folks,

Yesterday I made a variety of performance enhancements, working with Andi.

One change was to freeze the wx column headers when changing their text, 
  on Windows and Mac this seems to make rendering quite a bit faster, we 
change the headers seven times, one for each day of the week, I suspect 
(thought I'm not sure, I didn't track down what was happening in the 
change label calls) before the freeze we were repainting lots of things 
for each label change to a day.

Another change was to optimize lookup for events that ought to be 
displayed this week by assuming no event is longer than one week.  I'll 
be special casing events longer than a week so we still handle them, but 
my expectation is there are far fewer of these on most calendars.

Finally, I used Andi's new sub-index support to iterate over many fewer 
repository keys when looking for recurring events that might have an 
occurrence that should be rendered in the current week.

I'm getting interesting results comparing profiling go-to-next-week 
calls on my WinXP Dell and my Intel Mac.

In a nutshell, the changes from r10943 to r10946 show similar changes to 
the number of calls to iterindexkeys, the numbers of calls on each 
platform go from 48000 to less than a thousand.

Intriguingly, on the Intel Mac, the actual time taken to call 
iterindexkeys 48000 times (it's a generator, so that's 48000 entries, 
not really calls) in r10943 is ~5% of the 250ms or so it's taking to 
switch weeks.

On the (50% faster CPU) Dell, it's more like 15% of 350ms per week 
switch.  That's an oddly big difference in performance for that call 
between the two platforms.  The Intel Mac does have a faster hard drive, 
so if iterindexkeys is IO bound, that could explain the discrepancy.

These profile results match my subjective experience of using the 
calendar on the Dell compared to the Intel Mac, on the Dell I've been 
noticing the calendar being really slow to switch weeks of late, on the 
Mac the calendar is surprisingly fast, I don't notice a rendering delay 
except for periodically when Chandler hangs for 5-10 seconds when I 
haven't changed anything (this is, of course, weird, but likely a 
different issue).

One other thing I realized when testing is that the change in r10945 to 
generate recurring events in range more efficiently is likely to help 
rendering of calendars with significant numbers of non-recurring events 
in the past, without much gain for calendars that have mostly recurring 
events.  As it happens, our performance tests are using a calendar with 
2689 recurring events (times 9 occurrences each) and 311 non-recurring 
events.

We may want to change our performance test data to have more 
non-recurring events in the past, I suspect normal users have more 
non-recurring than recurring.

Sincerely,
Jeffrey