Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Date parsing performance on iOS (NSDateformatter vs sqlite)

vombat.tumblr.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#51

Post by dpratt »

dante_dev wrote: post #25

mmm.....can I see the code about NSDateFormatter? because I feel like you're using it wrong. You need to cache somewhere the NSDateFormatter allocation (it is really expensive), reusing the same instance to convert the string to NSDate*.

Sadly, NSDateFormatter (and NSFormatter in general) are explicitly not thread safe. You'll either have to just allocate and release on demand or implement some sort of thread-local mechanism. Unfortunately, one of the drawbacks do the (generally excellent) concurrency APIs in macos/iOS is that thread locals are actually sort of a pain to implement. I've been writing cocoa apps for a few years now, and I find the platform to be generally quite good, but I do miss things like Joda time.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#52

Post by azinman2 »

stevoski wrote: post #33

A class like NSDateFormatter is designed to handle a wide range of date formats. This usual results in sub-optimal performance. If you find it too slow and you have a known, specific date format you should write a specific fast parser. I did the same with Java's Integer.parseInt(...) method. It is an interesting task to go through. Now I'll spend the rest of this rainy afternoon playing around with writing a fast ISO…

So are you going to post that iso parser?

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#53

Post by gilgoomesh »

stevoski wrote: post #33

A class like NSDateFormatter is designed to handle a wide range of date formats. This usual results in sub-optimal performance. If you find it too slow and you have a known, specific date format you should write a specific fast parser. I did the same with Java's Integer.parseInt(...) method. It is an interesting task to go through. Now I'll spend the rest of this rainy afternoon playing around with writing a fast ISO…

It does seem as though Apple should implement a separate optimized path for the very common case of ISO-8601 date formats.

Although I'm not sure how many people on iOS need millions of dates parsed.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#54

Post by TheZenPsycho »

haberman wrote: post #49
hughw wrote: post #45

Earlier quoted context omitted.

It's frequently important to preserve the original time zone offset of a timestamp. Sending everything as UTC loses that information.

There is nothing preventing you from sending a time zone offset (or an Olson timezone id like 'America/Los_Angeles') along with the Unix Time.

Sure no problem. We just have to invent a new format.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#55

Post by TheZenPsycho »

rorrr2 wrote: post #9
pilif wrote: post #3

>Many web services choose to return dates in something other than a unix timestamp (unfortunately) Wrong. That's very fortunate. Unix time stamps have some serious deficiencies as data type for storing time information: for one, they lack precision. One second just might not do it. Then they lack any time zone information. You will never know what a specific time stamp is in. GMT? UTC? Time zone where the server is i…

Unix timestamps are always UTC (GMT) Quote: > Unix time, or POSIX time, is a system for describing instants in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970

Uhm, UTC != GMT Nobody in this comments thread knows what they're talking about and I wouldn't trust anyone here to program anything to do with time.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#56

Post by DannyBee »

colanderman wrote: post #17
rorrr2 wrote: post #9

Earlier quoted context omitted.

Unix timestamps are always UTC (GMT) Quote: > Unix time, or POSIX time, is a system for describing instants in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970

More importantly (the GP missed this as well), Unix timestamps can't convey local time . Local time has UI implications, e.g. the query "is this event on a weekend" is not generally answerable without the time zone.

Entirely true, but not necessarily relevant.

Local time is a weird thing and changes all the time.

For giggles, look at the history of timezone rule changes in tzdata.

Most timezones have at least one duplicate hour per year (IE the same time occurs twice) in the US as well.

Local times are not an appropriate way to store time.

Note: ISO8601 does not give you local time anyway, since you cannot infer the timezone from the time offset.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#57

Post by DannyBee »

haberman wrote: post #48
pilif wrote: post #3

>Many web services choose to return dates in something other than a unix timestamp (unfortunately) Wrong. That's very fortunate. Unix time stamps have some serious deficiencies as data type for storing time information: for one, they lack precision. One second just might not do it. Then they lack any time zone information. You will never know what a specific time stamp is in. GMT? UTC? Time zone where the server is i…

You are criticizing things which you do not understand (and getting upvoted for it on HN, which is a little disturbing). As others have mentioned, Unix Timestamps can be arbitrarily precise by adding arbitrarily many places of decimal precision (and this is common practice, supported by the Unix "date" command, among other things). Secondly, Unix Time is an absolute timescale that is not relative to any time zone. A…

I can't upvote this high enough. Anybody who thinks iso8601 dates are a good way to store time should not be allowed to handle time.

The same hour does also not occur twice in unix timestamps, though it does in most timezones (but not time offsets). Conversion rules are a mess, and have changed over time.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#58

Post by MishraAnurag »

andymoe wrote: post #47

> To parse a million randomly generated dates on an iPhone 5 running iOS 7, NSDateFormatter took a whooping 106.27 seconds, while the SQLite version took just 7.02 seconds. Yes, NSDateFormatter is slower than other methods including some C libraries out there or this novel approach for turning a string into a NSDate however in most instances it's plenty fast enough and has a bunch of useful functionality [1] the leas…

That's a fair point. NSDateFormatter is fast enough and you should never replace it for anything else unless you know for sure that it's a problem. Well that goes for any optimization. In my particular case, it was really a bottleneck, and the time difference of 100 seconds vs 7 seconds meant a user will not have to wait for 93 seconds during the initial import step. I am not suggesting we start getting rid of NSDateFormatter as it is a very valuable tool which we use for any and all date formatting ourselves, just not during massive imports anymore.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#59

Post by Tloewald »

TheZenPsycho wrote: post #55
rorrr2 wrote: post #9

Earlier quoted context omitted.

Unix timestamps are always UTC (GMT) Quote: > Unix time, or POSIX time, is a system for describing instants in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970

Uhm, UTC != GMT Nobody in this comments thread knows what they're talking about and I wouldn't trust anyone here to program anything to do with time.

As far as I can tell, GMT is now UT1 which may not diverge from UTC by more than one second. I don't think conflating the two is especially egregious in this context.

Re: Date parsing performance on iOS (NSDateformatter vs sqlite)

#60

Post by Tloewald »

haberman wrote: post #46
thristian wrote: post #20

Earlier quoted context omitted.

Another good reason to avoid POSIX timestamps: they ignore leap-seconds. Thus, to determine how many (for example) days are between two timestamps, you need an up-to-date database of leap-second insertions. Maybe an error-bar of a few seconds doesn't sound like much, but if that error bar happens to straddle midnight and (like most code) you get a date-stamp by truncation, you could be off by a day. If that error-bar…

Why would you ever care about leap seconds when calculating the number of days between timestamps? Leap seconds are necessary to calculate the exact number of seconds between two timestamps. But a day isn't exactly 86,400 seconds on leap second days, it's a little bit longer. So the simple algorithm for calculating the number of days between timestamps (floor((ts2-ts1)/86400) seems more correct than anything that tak…

A leap second only lengthens one day.

In any event POSIX time stamps are fine w.r.t. leap seconds, it's the conversion functions which may or may not reflect them.

Post reply on HN