iCal Scalability

I switched to using iCal when my MacBook Pro became my primary email machine a while back. Continuing to run Outlook was too much trouble because it meant keeping a virtual machine running all the time. I tried Entourage, too, but iCal was simpler yet sufficient for my needs. True, iCal doesn’t integrate with our corporate calendaring solution–but in my job that apparently doesn’t matter much.

I found that iCal under 10.4 was a bit on the slow side. Performance enhancements were rumored for 10.5; another reason to look forward to the upgrade. Yet after the upgrade, iCal seemed as slow as ever–and sometimes worse. It’s easy to find complaints about iCal on the web, I couldn’t find many practical steps for speeding up. Time to do a little digging.

My events are divided among five calendars. With all five displayed, even changing the view from week to week was slow. I’d seen one reference on the web about a particular calendar giving someone trouble, so I tried mine one-by-one. Sure enough, just one calendar–let’s call it “A”–was responsible for the slowdown.

This matched up with a hunch of mine: there was a repeating event on calendar A that was basically un-editable in iCal. It didn’t cause a freeze or crash, but it hung iCal up for so long that I never had the patience to wait it out. Searching through the calendar event-by-event for a troublemaker could take a long time; starting with this troublemaker seemed like a good idea.

First, I exported the calendar to an .ical file which–thankfully–is a line-oriented text format. It was over four megabytes. Running “grep SUMMARY A.ical | wc -l”–SUMMARY is the field that contains the name of each event–showed it contained about twelve thousand events. I’m busy, but I’m not that busy.

Following up on my hunch, I searched manually for the repeating meeting. There were many, many instances–over eleven thousand. That’s a lot–so many that if I’d been to this meeting once a day, every day since I was born I would had my eleven thousandth meeting just a few years ago.

How did there get to be so many instances? That I don’t know. I suspect it’s related to the fact that this meeting occurs four days a week, so there’s probably no built-in recurrence rule for it. Worse, on one of those four days the meeting is in an alternate location, so that’s an additional exception to the recurrence. Even so, eleven thousand is clearly excessive.

Should iCal have been able to handle this event without slowing excessively? Hard to say. It’s not a large number of events in absolute terms; someone with ten years of experience and eight meetings a day would have more events in their calendar. Still, I suspect iCal scales more gracefully across a large number of different events and that the culprit here is the bizarrely large number of instances for the same (recurring) entry.

I removed all instances of the meeting by hand, deleted the original calendar, and imported the patched up version. Result? iCal is fast again.

Bonus question: Given what little I’ve said about our development process, what meeting do I attend four times a week?