As written, 70 microseconds. When I set the calendar's time zone to
GMT, the
time drops to 43 microseconds. Since my app will only work with
dates in
GMT, this is a plus. Even so, 40 microseconds is far slower than the
7 - 8
microseconds offered by -[NSCalendarDate dayOfYear]. Unless someone
has
another offering, I plan to file a bug report on this issue. This
calculation is part of an animation loop, so the performance hit is
important.
Sorry to jump in late, but I am just now getting around to reading
about 5 days worth of email. Did you try caching the NSCalendar
creation call? I believe we had a similar performance issue with
CFCalendar (which no doubt shares its implementation with NSCalendar),
and I found out with Shark and fs_usage that each CFCalendarCreate
call results in many (very large) region data files being read into
memory. <sarcasm>Turns out reading several megabytes from the
filesystem is expensive</sarcasm>, so caching the CFCalendarCreate
resulted in a big performance gain. Not sure if NSCalendar implements
any caching on its own, but you might give it a shot.
Ryan
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
