On Oct 20, 2008, at 10:31 PM, Michael Ash wrote:
On Mon, Oct 20, 2008 at 1:35 AM, j o a r <[EMAIL PROTECTED]> wrote:
Some general suggestions for best practices wrt. optimizations:
1) Measure first
2) Implement supposed optimization
3) Measure to see the impact of the code change
4) Based on the result of #3, either scrap your changes,
or
document the optimized code
And don't forget step 0:
0) Don't even bother
A lot of people optimize code that's already plenty fast. A lot of
people optimize code that *hasn't even been written yet*. This is
foolish. Write your code to be easy to understand and as bug-free as
you can get it. And then, only if it's not running as fast as you need
it to, should you even start to consider the possibility of thinking
about beginning to investigate optimizing the code.
Mike
_______________________________________________
I'm not sure I totally agree with step 0. I think there is value in
understanding how your code is going to run, or is going to run most
times, and picking constructs which are clearly efficient if it's
really not more work to do so and it represents the data you're
working with.
I was working on something similar this weekend, converting a wire
protocol into NSStrings, bytes were 100% guaranteed ascii. I could
have converted the entire original data to one string, then split it
into an array of strings on certain characters, then put it together
again, and were it unicode or something similar, I would have. But
instead I scanned the byte array once, found the bits I wanted and
made the final strings the first time around using the string
constructors from void*/length. It was no more code, it took a bit of
thought about the data structure but it does avoid a load of creation,
copying and destruction of strings.
I think that's just good programming. If I know when I'm creating an
array that it's going to have 139 elements but I'm going to add them
one by one, I'm going to make an array with capacity for 139 elements
right up front. If I don't, then I'm going to trust the framework to
do the best job it can and take the overhead.
Premature optimisation is a fuzzy line, it's easy to go overboard with
it, but there's definitely a place for considering whether the code
you're writing is going to create 10 objects, them copy them 8 times
to something else, instead of making one of the right size the first
time and filling it once.
That said once I'm done I always run the optimization tools at the
end, but I do program with some thought of efficiency in mind.
_______________________________________________
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]
