On Dec 9, 2008, at 7:25 PM, I. Savant wrote:
On Dec 9, 2008, at 8:09 PM, Ricky Sharp wrote:
In some cases, other attributes, when set, will 'dirty' that flag
followed by a setNeedsDisplay. Colors will then be re-fetched/
created and then reused until the next change comes along.
Perfectly good example of "timely optimization".
The main reason (which I may not have communicated clearly) is
because any unnecessary work at all is wasteful. Especially for
mobile platforms (laptop and iPhone users will thank you for sparing
their battery life ... or curse you for not caring).
Asking for the shared user defaults instance, then asking it for a
value, then unarchiving a more useful object from it, *then* using
it to draw is certainly more work than caching the value only when
it changes. It's not like it's performance tuning - it's *basic
design*.
I suppose I'm from the camp of developers that started in the days of
8-bit CPUs with limited memory. My coding style tends to be very
conscious of resources. I also have quite a bit of embedded
experience, so that further reinforces that style.
I've never seen situations where one wastes resources and doesn't at
some point later have to refactor lots of code. This typically comes
into play not only when going embedded, but when massively scaling
your app upwards.
___________________________________________________________
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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]
