Re: How Can I Notify DrawRect Method?
Re: How Can I Notify DrawRect Method?
- Subject: Re: How Can I Notify DrawRect Method?
- From: "Michael Ash" <email@hidden>
- Date: Tue, 9 Dec 2008 22:32:57 -0500
On Tue, Dec 9, 2008 at 8:25 PM, I. Savant <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden