Re: ObjC in time-critical parts of the code
Re: ObjC in time-critical parts of the code
- Subject: Re: ObjC in time-critical parts of the code
- From: Justin Carlson <email@hidden>
- Date: Fri, 16 Jan 2009 16:26:36 -0600
Sorry if I come across as the devil's advocate on this one - I think
there should be another voice stating that objc use can slow a program.
Compared to C or C++, Objective C is a poor choice for performance
critical code. Within performance critical zones, I will only use objc
objects for very high level objects, and even then, rarely. I do use
objc objects for things such as user interfaces. I've done a few
ports, even for standard application level programs (omitting
graphics), the difference is typically several times faster. I've made
libraries which use C and C++ objects/interfaces, objc programs which
are modified to use these libraries are noticeably faster. If a
program needs to be fast, objc cannot compete with C or C++ objects
(unless the programmer has missed important concepts of oo design or
for some other unusual reason).
In short, I typically saw changes of 5 - 8 times the speed when
converting class families/libraries to C++ for standard application
code. That is just a change of the class' language - no complex
optimizations there (other than what GCC includes), most programs can
be optimized well beyond that point. I don't use objc objects for
performance critical code - and, yes, I have spent much time with
performance tools on this and other areas. The explanations for these
differences obviously extend beyond 'how fast can a nop objc method be
sent 1000 times in a row'? -- I don't need to convince anybody to use
one approach over the other (it sounds like everybody is already
convinced, anyhow!), I just thought I'd state that there significant
gains can be made by simply avoiding objc objects in performance
critical code (which back up both sides of the argument). I don't
actually have hours to explain why this is so -- It shouldn't require
an optimization expert to conclude (or reason) why the difference is
so large. Besides, if your program needs that kind of speed, the best
thing you can do is figure out why the difference exists. Other
bonuses typically include significantly smaller executables and fewer
exported symbols.
J
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden