On Tue, Dec 9, 2008 at 8:25 PM, I. Savant <[EMAIL PROTECTED]> 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).
This is a common response whenever I talk about not optimizing where it's not useful. But the thing is, trying to optimize every little thing makes your app *slower*. Imagine building a bridge to be as lightweight as possible. You *could* start by putting together plans for a bridge, then going over every bolt in the thing and shaving a bit of metal from each one. Of course you'll have gone through only a miniscule fraction of the bolts in the bridge before the people who hired you to build it get fed up and tell you to open it for traffic or get lost. Result: a very heavy bridge. Or you could forget about shaving the weight of the bolts, let them be heavier than needed, and concentrate on saving weight in the parts of the structure where it really counts. Use half the number of bolts and you've already done more than you ever could have before. Lighter materials, better supports, less redundancy, all will save you big. But you won't have time to find any of that if you spend your days shaving the unimportant parts off your bolts. So it is with programming: you build the fastest code by concentrating your optimization effort in the places where it can do the most good. > 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*. This is far from basic design. It's a pure implementation detail. It's the sort of thing you could come back and switch easily if you decided that it really was too slow when put up against the real world. It's just simple caching, which never needs to be designed in advance. Basic design would be things like using appropriate data structures, threading vs multiplexing, good data stores, and other such big-picture things. Mike _______________________________________________ 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]
