Re: objective-c / cocoa efficiency
Re: objective-c / cocoa efficiency
- Subject: Re: objective-c / cocoa efficiency
- From: John Stiles <email@hidden>
- Date: Tue, 8 Mar 2005 14:41:32 -0800
I would think it would be up to the project manager to demonstrate
these inefficiencies. In practice, I haven't seen problems where Cocoa
was wasteful of cycles. AppKit provided acceptable performance back
when it was called NeXTstep and it ran on 33MHz 68030s; I see no reason
to think that it would be less efficient today.
Use Shark on your application and see where it's slow. If it is, in
fact, AppKit that is causing performance issues, then revisit the
hotspots and use lighter-weight constructs where you can. I suspect
that he is making blatant assumptions. The good news is that Apple
provides tons of performance-measurement tools so it is trivial to
prove or disprove his theory.
On Mar 8, 2005, at 2:18 PM, Barton J. Friedland 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:
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