Taming NSDate-Utilities

NSDate-Utilities is a part of a great library for working with NSCalendar and NSDate. It provides uber-convenient methods on NSDate for finding out, for example, whether the NSDate receiver falls within the current day. These utilities are fantastic, but unfortunately, they’re also a bit on the slow side.

Why so slow?

Many of the methods rely on getting NSDateComponents from a date via the NSCalendar. Each sends an independent call to [NSCalendar currentCalendar]. Unfortunately, getting the current calendar seems really slow. The latest SalesBag release will feature a very robust set of calendar views to help salespeople schedule their meetings. This means a ton of calculations on NSDate inside tight loops. Using the NSDate-Utilities methods and the time profiler, I found the app spending nearly half a second in [NSCalendar currentCalendar]. This is not good.

Diagnosis

The NSDate-Utilities methods that spend time with NSCalendar all call out to [NSCalendar currentCalendar] independently. For general use, this is probably fine and leaves the app a little leaner on memory. It also (seems to) guarantee that the calendar will always be right if the user changes it mid stream in the app. For Salesbag, this won’t be a problem. We assume that salespeople in the US will be using the gregorian calendar.

Fixing

To speed things up I first created a static NSCalendar variable at the top of the m file that we’ll use in place of grabbing NSCalendar fresh every time.

static NSCalendar *curCalendar = nil;

Then I replaced the #define for current calendar with my static variable

#define CURRENT_CALENDAR curCalendar

Lastly, I need to create the calendar when needed. For this I created a new macro that I placed at the head of any method using the CURRENT_CALENDAR macro:

#define INIT_CURRENT_CALENDAR if (curCalendar == nil) curCalendar = [[NSCalendar currentCalendar] retain];

// later ...
- (BOOL) isSameYearAsDate: (NSDate *) aDate
{
    INIT_CURRENT_CALENDAR
	NSDateComponents *components1 = [CURRENT_CALENDAR components:NSYearCalendarUnit fromDate:self];
	NSDateComponents *components2 = [CURRENT_CALENDAR components:NSYearCalendarUnit fromDate:aDate];
	return ([components1 year] == [components2 year]);
}

Improvement

The time profiler showed the time spent in [NSCalendar currentCalendar] dropped to a measly 35ms. Something I can certainly live with. Of course there’s no such thing as a free lunch and any developer would point out that my static won’t be deallocated until the app terminates. In this case though, the memory trade off was worth it for the speed increase.

Advertisements

Posted on February 21, 2012, in Libraries and tagged , , , . Bookmark the permalink. 1 Comment.

  1. This valuable posting, “Taming NSDate-Utilities Pat Zearfoss”
    displays that you really fully understand precisely what u are speaking
    about! I really fully agree with your blog. Thank you -Lily

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: