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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
