Re: objective-c / cocoa efficiency
Re: objective-c / cocoa efficiency
- Subject: Re: objective-c / cocoa efficiency
- From: The Karl Adam <email@hidden>
- Date: Tue, 8 Mar 2005 17:46:43 -0500
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:
>
> 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