Re: objective-c / cocoa efficiency
Re: objective-c / cocoa efficiency
- Subject: Re: objective-c / cocoa efficiency
- From: Charlton Wilbur <email@hidden>
- Date: Tue, 8 Mar 2005 19:52:12 -0500
On Mar 8, 2005, at 5:18 PM, Barton J. Friedland wrote:
It seems, however, that the project manager of the application I
contributed code on thinks differently (pardon the pun).
Here are some of his comments:
"I am not going to accept something that causes a thousand garbage
objects to be collected in one event cycle.
Not optimizing where speed is not a concern is one thing. flagrant
inefficiency is something else."
If the thing that needs to be done requires a thousand objects to be
created and disposed of in one event cycle, then it will happen whether
they're part of an autorelease pool or not. If the thing that needs to
be done doesn't require a thousand objects to be created and disposed
of, then that's not going to happen in Cocoa any more than it is in
straight C, and the guy is just being a twit.
"And so you are using a NSString isEqualToString: which can handle
every script known to man and has to be aware of encodings instead of
simply using a switch statement and == which is probably at least a
hundred times faster per character."
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.
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.
That said, there are issues of style here.
if ([case isEqualToString: @"caseOne"]) { ... }
else if ([case isEqualToString: @"caseTwo"]) {...}
else if ([case isEqualToString: @"caseThreee"]) {...}
else {...}
is going to be slower than
#define OSPCaseOne 1
#define OSPCaseTwo 2
#define OSPCaseThree 3
switch (case) {
case OSPCaseOne:
...;
break;
case OSPCaseTwo:
...;
break;
case OSPCaseThreee:
...;
break;
default:
...;
break;
}
The latter is not less comprehensible to the programmer, which is where
the premature optimization problem usually shows itself. In real code
you would probably give the #defines much broader scope, and use them
as symbolic constants more widely than just the switch statement. This
also has the advantage that it gives the compiler a chance to catch
some common types of bug; I inserted a typo in both cases, but the
compiler would only catch it in the version with the switch statement.
(My own conclusion at this point would be that the maintainer is a
twit, and I'd probably thank him for creating a useful project and find
other things to do with my time than contribute code to a project that
treats a donation of time and effort that ungraciously.)
Also, what kind of profiling tools could I use to prove these
statements
as either true or false?
There's a wonderful tool called Shark, part of the developer tools,
that will show you where the application is spending most of its time.
Performance tuning of Cocoa applications is not something I have spent
a lot of time on yet, but that should give you a start.
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
email@hidden
_______________________________________________
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