Blog Archives

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.


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.


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
	NSDateComponents *components1 = [CURRENT_CALENDAR components:NSYearCalendarUnit fromDate:self];
	NSDateComponents *components2 = [CURRENT_CALENDAR components:NSYearCalendarUnit fromDate:aDate];
	return ([components1 year] == [components2 year]);


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.

Some great iOS links from the past week.

Here’s a roundup of some of the things I’ve been reading from around the web this week:

Building mobile applications course at Harvard Extension School. I’ve been meaning to learn some android development. I think this is where I’m going to start.

NounProject – Need some icons for your next app? Give these a look!

Catching integer overflows in C – It certainly doesn’t come up very often, but every once in a while you’ll have to deal with integer overflows. This article details what they are and how to catch them.

Nextive JSON parser – I haven’t had opportunity to try this out yet, but word on the street is this is the fastest JSON lib around.

When Patents Attack – produced by NPR and This American Life, this expose talks about patent trolls like lodsys and their shady business practices. Here’s the direct link to the This American Life Podcast.

New iOS Devs Shouldn’t Use IB – Like this author, I’m an IB convert but when I started I was doing all my interfaces in code. The author talks about why all iOS devs should start like this. What do you think?

25 Amazing Open Source iPhone Apps – There’s no better way to learn than seeing how others do it. Check out these open source iPhone products.

10 iOS Libraries + 2

AppDevMag posted a list of 10 libraries to make iOS development easier. We’ve used Three20 and a few of the others here at Mindgrub, and wound up writing our own library similar to ASIHTTPRequest back in the iOS 2 days, though it was built around NSHTTPURLRequest rather than CFNetwork.

Two great libraries they left out however:

  • ShareKit – Post to many social network sites out of the box. This library is light and fast, and easily extendable to add other services.
  • XMLRPC in WordPress for iOS – Writing XML-RPC from scratch is a pain, but this library will get a lot of the boiler plate code out of the way. The app is open source.