Re: objective-c / cocoa efficiency
Re: objective-c / cocoa efficiency
- Subject: Re: objective-c / cocoa efficiency
- From: Andy Armstrong <email@hidden>
- Date: Wed, 9 Mar 2005 13:56:41 +0000
On 9 Mar 2005, at 00:52, Charlton Wilbur wrote:
I'd doubt that it's 100 times faster. Beyond that, you can't use
strings meaningfully in a switch statement, or safely compare strings
with == in C *anyway* -- what you wind up comparing is pointer values
cast to integers, which have no necessary correlation with the
contents of the string.[1] Locale-aware strncmp() -- which is what
you'd have to use anyway -- is not going to be that much faster than
-isEqualToString:, with most of the difference probably being the
result of dispatching the method.
[1] Well, with one exception: constant strings known at compile time
to be constant and read-only may have the same pointer value.
And any two char pointers that compare equal with == are guaranteed to
point to the same thing and therefore be equal strings, so in cases
where optimisation does matter (and we clearly haven't established that
this is one of those cases), checking the two pointers for equality
before doing a character by character compare can make sense -
especially as a character by character comparison that compares equal
is the worst case - it has to compare all the characters in the two
strings. Of course strcmp() and any other string comparing function
probably have the == check in there anyway.
Can someone enlighten me here? I have written my code as per the Apple
guidelines as I understand them. Is there some secret horrible
inefficiency with Cocoa and / or Objective-C that I should know about
in order to satisfy the needs of this type of programmer?
It's not a horrible inefficiency; it's premature optimization. The
Cocoa frameworks were designed by people who placed a much higher
value on resilient code that worked in lots of situations than they
did on squeezing every possible cycle out of the processor. There's a
school of thought (and I am *solidly* in that camp) that holds that
programmer time is more important than computer time; if you value a
programmer at $50/hour, then a tricked-out dual-G5 Power Mac costs
less than two programmer-weeks. As a result, the right thing to do is
to write the code cleanly, then optimize the bottlenecks as necessary.
I'd rather sacrifice a dozen cycles here and there (the low-end Mac
mini has 1.2 *million* cycles per second to use up, after all) and
find that the software Just Works when it's time to create a Japanese
localization than have to spend many programmer hours rewriting the
code to fix all my broken assumptions about what string comparison
involves.
We're moving off topic here but, as stated, the 'programmer time more
expensive than computer time' argument compares apples with oranges.
Programmer time is expended once - program execution time is expended
every time that program executes.
In fact if you have software that's used five days a week by 50,000
users for a period of three years and you waste just one minute for
each of them every day then you've wasted a total of around 80 years -
or an entire human life. Murder by sloppy programming if you will :)
I'm not advocating premature optimisation but we do at times seem to be
drifting the other way into the belief that Moore's law will make
everything alright and that we're so valuable to that we shouldn't
waster our precious cycles when the computer's cheap cycles can be
spent instead.
--
Andy Armstrong, hexten.net
_______________________________________________
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