Please do jump in late, especially with a 20 microsecond suggestion. Full details are at
http://bersearch.com/PrivateTechSupport/NSCalendarBenchmark/NSCalendarBench mark1.0.zip I have filed a bug report titled Planned NSCalendarDate deprecation yields slower performance Bug ID# 6179834 Thanks again to you and to Eliza Block for your suggestions. ++ Tom Tom Bernard [EMAIL PROTECTED] on 8/22/08 12:00 AM, Ryan McGann at [EMAIL PROTECTED] wrote: >> 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. _______________________________________________ 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]
