4 ms·
I was wondering the same thing since that's also what apple recommends in situations like these. This is what I got on the same hardware: strptime_l took 58.80
by jurre 13y ago
I was wondering the same thing since that's also what apple recommends in situations like these. This is what I got on the same hardware:
strptime_l took 58.803 seconds
NSDateFormatter took 107.570 seconds
sqlite3 took 7.022 seconds
And with MishraAnurag's suggestion of using timegm instead of mktime:
strptime_l took 21.656 seconds
NSDateFormatter took 108.163 seconds
sqlite3 took 7.096 seconds
- coldcode 13y agoWhy not see what sqlite is doing and do something in C yourself that solves the actual problem. It's not surprising that a general purpose Obj-C (or any language) class isn't terribly fast at one specific thing.
- jurre 13y agoYeah that would probably be the way to go ultimately if you're doing a lot of date parsing, I agree!
- MishraAnurag 13y agoAre you using mktime to get the unix timestamp? That might be the slower part as opposed to strptime.
- jurre 13y agoI am, source is here: https://gist.github.com/jurre/6475263 https://gist.github.com/jurre/6475263 My c is quite poor so if you have any suggestions on how to improve I'd love to hear them!
- MishraAnurag 13y agoI'd suggest using timegm instead of mktime, or set the TZ environment variable to UTC to ensure all implementations return an identical date. I ran the same tests and found that the strptime was quite fast, but gmtime was taking most of the time. To speed that up, you could borrow SQLite's implementation. Checkout the computeJD function from SQLite's date.c - http://www.sqlite.org/src/doc/trunk/src/date.c http://www.sqlite.org/src/doc/trunk/src/date.c
- jurre 13y agotimegm actually already makes a huge difference, thanks! Might be useful to make a small fast date parsing library based on the sqlite source code.