RE: objective-c / cocoa efficiency
RE: objective-c / cocoa efficiency
- Subject: RE: objective-c / cocoa efficiency
- From: Jeff Laing <email@hidden>
- Date: Wed, 9 Mar 2005 12:22:51 +1100
Ok, I'll do the devils advocate thing...
> From: Charlton Wilbur [mailto:email@hidden]
> On Mar 8, 2005, at 5:18 PM, Barton J. Friedland wrote:
>
> > "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.
Well, imagine I have a (admittedly) badly structured loop that runs 1000
times and on each iteration, it creates a temporary object it expects to be
autoreleased "later".
Structuring it properly (by releasing it yourself in the loop) may be
non-trivial (though its hard to come up with a trivial example that doesn't
involve calling other methods whose contents you can't predict).
The key here is "requires a thousand objects" with the emphasis on
"requires". Sloppy Cocoa code *can* results in hundreds of objects being
left to auto-release themselves "eventually" - it doesn't need to be a loop
that does it, just some cascading methods calling other methods, each of
which relies on autorelease.
> > "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
Um, no, I've seen zillions of programs that do this:
switch (*s) {
case 'a':
if (strcmp(s,"a_command")==0) ...
if (strcmp(s,"another_command")==0) ...
break;
case 'b':
if (strcmp(s,"because")==0) ...
if (strcmp(s,"buggrit")==0) ...
break;
etc...
where doing a switch on the first character in your candidate can reduce the
number of string comparisons by a factor of 256 (worst case).
Replacing the above strcmp() with -compare works, but you need to be a
little more careful about extracting that first character.
(Yes, this is way suboptimal, use a hash-table or something similiar or
better, a flex parser - in both cases, these are harder to code and keep
straight during development (when addition of new keywords require more than
just a .c recompile)
> (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.)
My guess is that there's an existing code-base, with coding standards, etc
which were put in place to ensure that everyone worked "on the same page"
rather than re-inventing their own incompatible ways of doing things.
And frankly, he's sick of explaining to every graduate that comes along that
"we do it this way because this way has been proven to work, given our
experience of the quality of work we get from our programmers".
(Note: I am *not* related to this project in any way, I've just had one too
many graduates come along, dump a bunch of unmanageable C++ into my systems
(because they knew better), quit and leave a pile of crap that needs to be
replaced because it only works in exactly the scenario their limited
experience envisaged, not in all circumstances that the original system
designers knew, understood and usually explained to blank stares)
As to:
> the low-end Mac mini has 1.2 *billion* cycles per second to use up
... yours might, mine sure as hell doesn't, its busy running those *other*
apps as well, which is why I bought a multi-tasking operating system. I
want to be doing my 3D renders while your app is chugging away.
_______________________________________________
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