Re: objective-c / cocoa efficiency
Re: objective-c / cocoa efficiency
- Subject: Re: objective-c / cocoa efficiency
- From: Matthew Johnson <email@hidden>
- Date: Tue, 8 Mar 2005 19:19:15 -0600
It looks like you're working on Super Collider. Who is the project
manager for that? I believe the guy that originally wrote it is now
working for Apple. If he's still in charge I think he probably knows
what he's talking about, and for this app performance per event loop
could indeed make an important difference (it's a real time audio
programming language for those who don't know about it)...
Matthew
On Mar 8, 2005, at 5:31 PM, b a r t o n wrote:
Here is the implementation diff - tell me what you think.
On Tue, 8 Mar 2005 17:46:43 -0500, The Karl Adam <email@hidden>
wrote:
We would need to see some of the code you submitted, but if teh
-isEqualToString comment is any indication, then this developer is
sacrificing a great deal of functionality for pretty nominal speed
increases. In this case he is sacrificing support for multibyte
strings and smart comparisons of accented chars for a few
milliseconds. This is not to say that the isEqualToString: method is
the fastest in teh world, but rather it has an overwhelming amount of
functionality to make up for its lack of raw speed.
If this developer truly feels this way his project will be plagued
with weird functionality and bugs that have long been stomped out by
the mature Cocoa apis, not to mention the amount of time he will spend
tracking down silly bugs that are there simply because he didn't want
to use the code of people that have much more experience on this sort
of thing.
If you don't mind, can you share the code and or project that you are
attempting to work with?
-Karl
On Tue, 8 Mar 2005 14:18:53 -0800, Barton J. Friedland
<email@hidden> wrote:
I am working on an open source project where the UI is written in
Cocoa.
It therefore seemed natural to me to use as many of he Cocoa objects
as
possible, since it appears from the detailed documentation that a
significant number of person-years has gone into the development of
these frameworks. I would therefore expect them to not only be
reliable, but efficient.
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."
"It isn't just the typing response. The main thread is used for
updating
the UI and things scheduled with AppClock, so it is really unfriendly
to other tasks to be throwing away CPU cycles like you had an
infinite
number to burn."
"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."
---
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?
Also, what kind of profiling tools could I use to prove these
statements
as either true or false?
Any help or information would be appreciated.
Thanks,
Barton
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
<bjf_brace_patch_source.txt>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to 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