NSDateFormatter localizedStringFromDate performance

[twild]

During my configureCellForIndexPath (called by CellForRowAtIndexPath) I am taking a date in GMT and converting it to the user's date/time. I am using NSDateFormatter's localizedStringFromDate method. Everything works, but it is taking a huge chunk of time to format the date. I used the TimeProfiler Instrument and found that this method slows down drawing my cells considerably:

configureCell time:
----------------------------------------------------
Using localizedStringFromDate: 97 ms

Hard-codeing a date: 8 ms

Is there a faster way to convert the date from GMT/UTC to the user's localized date in real-time? I'd prefer not to store it converted incase they move across timezones.

It runs ok on an iPhone4, but on a 3g scrolling through the UITableView is very choppy. Once I hard-code the date/time, it is very smooth.

[Duncan C]

Originally Posted by twild

During my configureCellForIndexPath (called by CellForRowAtIndexPath) I am taking a date in GMT and converting it to the user's date/time. I am using NSDateFormatter's localizedStringFromDate method. Everything works, but it is taking a huge chunk of time to format the date. I used the TimeProfiler Instrument and found that this method slows down drawing my cells considerably:

configureCell time:
----------------------------------------------------
Using localizedStringFromDate: 97 ms

Hard-codeing a date: 8 ms

Is there a faster way to convert the date from GMT/UTC to the user's localized date in real-time? I'd prefer not to store it converted incase they move across timezones.

It runs ok on an iPhone4, but on a 3g scrolling through the UITableView is very choppy. Once I hard-code the date/time, it is very smooth.

97 ms does sound like an awfully long time to do a date format. That's probably just "the cost of doing business", however, and no way around it.

Here's what I would do:

Add an NSString entry to your data model (usually an NSArray) for the formatted date string. Write your -cellForRowAtIndexPath routine to check to see if that string is blank, and fill it in using localizedStringFromDate if it IS blank. To get really fancy, have your cellForRowAtIndexPath display the cell with the date string blank, and generate an async request for a date string that re-displays the cell once the request is complete.

Don't save the formatted date string to disk, always generate it at runtime. That way, if the user changes time zones and relaunches your app, the strings will get regenerated. You can also have your model zero out all these date strings when you get an applicationWillEnterForeground message. (To keep things clean, I would suggest having your app delegate generate an NSNotificationManager notification message, which your table view's model can listen for.)

The final step will be to have your table view's view controller populate the date strings in it's -viewDidLoad method. You could probably get away with loading them all in one shot, synchronously. If you have hundreds of entries in the table you are displaying then you will want to create an NSOperationQueue/NSOperation to do this in the background. Write the routine to check to see if a given date string is blank, and only call localizedStringFromDate if the date string is blank.

[twild]

Originally Posted by Duncan C

97 ms does sound like an awfully long time to do a date format. That's probably just "the cost of doing business", however, and no way around it.

Here's what I would do:

Add an NSString entry to your data model (usually an NSArray) for the formatted date string. Write your -cellForRowAtIndexPath routine to check to see if that string is blank, and fill it in using localizedStringFromDate if it IS blank. To get really fancy, have your cellForRowAtIndexPath display the cell with the date string blank, and generate an async request for a date string that re-displays the cell once the request is complete.

Don't save the formatted date string to disk, always generate it at runtime. That way, if the user changes time zones and relaunches your app, the strings will get regenerated. You can also have your model zero out all these date strings when you get an applicationWillEnterForeground message. (To keep things clean, I would suggest having your app delegate generate an NSNotificationManager notification message, which your table view's model can listen for.)

The final step will be to have your table view's view controller populate the date strings in it's -viewDidLoad method. You could probably get away with loading them all in one shot, synchronously. If you have hundreds of entries in the table you are displaying then you will want to create an NSOperationQueue/NSOperation to do this in the background. Write the routine to check to see if a given date string is blank, and only call localizedStringFromDate if the date string is blank.

Excellent, thanks a lot Duncan C!