Re: + initialize docs conflict?
Re: + initialize docs conflict?
- Subject: Re: + initialize docs conflict?
- From: Shaun Wexler <email@hidden>
- Date: Wed, 2 Feb 2005 08:17:33 -0800
On Feb 2, 2005, at 7:42 AM, j o a r wrote:
Besides what Rick pointed out,
(; Yes, my bad! Not enough coffee yet. What I mistakenly thought I
noticed in Ricky's snippet was the sending of multiple identical
messages, which would all have identical results, thus much of that
messaging overhead could be eliminated. It was intended to be a
general "head's up", not a dig.
I wholeheartedly disagree with your suggested practice.
I would only create a local variable where:
1) it improves my ability to read the code, or
2) it provides an performance advantage that actually matters
#2 is definitively not the generally the case, and especially not in
the context of +initialize (which is most of the time only ever run
once). I would typically use it when enumerating over a larget number
of objects, and in that case also only after evaluating the possible
improvements by using a performance tool, like Shark. Another reason
to use #2 might be that you happen to *know* (from documentation or
benchmarks) that the method returning the value is expensive (it might
need to iterate over a list to return the value, or something
similar).
It _is_ good practice, and its cumulative effects add up considerably.
This isn't premature optimization; it's efficiency. General
programming laziness can slap the lead galoshes on an entire platform.
I do admit that I am a Sharkaholic, due in no small part to the
realtime nature of my app and its DSP and graphics frameworks. Such
things as avoiding LSU rejects, stalls and pipeline flushes, and other
general performance optimizations resulted in techniques that I've come
to employ in my standard coding practice. The proof is in the app. ;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden