Note no one that responded to Jens is stating that the Objective-C way
of doing message dispatching cannot cause performance critical
pathways to be "hotter" then desired compared to direct function
calls, C++ vtable dispatching, etc. The point has been that just don't
assume that is the source of a problem. Properly analyze what is going
on and then make adjustments.
Hi Shawn,
Of course. Benchmarks were provided, which only cover a portion of the
subject. Furthermore, vtables are not mandatory in all cases/calls. A
good optimizer (or properly written class) can overcome such
dependencies in several cases - optimization is far easier to
accomplish outside the constraints of the ObjC runtime. So you get
faster messaging, and more optimization control from C++ objects.
Also what Jens posted for the timings of message sends was WAY off
from the reality.
Ok. The test (and likely the cited benchmarks) are also unlike
standard program behaviour, though that was not the point I was making.
Anyway note using things like IMP caching in performance problem areas
will gain you speeds often better then you would via C++ vtable
dispatch. So you don't have to drop the use Objective-C because of
message send over head (in most real world situations).
-Shawn
Again, virtual calls are not always necessary components of
performance critical zones. That argument misdirects the point I was
making; that argument assumes C++ operates more closely to an objc
object than usual. I know about IMP caching, and other workarounds,
and yes, I did evaluate these options when doing the tests and ports I
cited in my response. For me, IMP caching, @defs punning and all other
such workarounds only served to complicate the program, and such
changes were outperformed in my tests/programs by properly written C++
objects.
The point I am making is: If you know you're working with performance
critical code, C interfaces or C++ objects/messaging will be slower
only in exceptional cases (assuming well written objects wrt the
language/messaging in use), objc objects will only complicate
opportunities for optimization (from several perspectives). Don't get
me wrong, objc a great oo language, but writing a standard oo
interface with it will either make your (performance critical) program
either comparably very slow or comparably slow and unnecessarily messy/
bloated/complex - In short, it is the wrong tool for the job. That is
my experience and my opinion. So my suggestion is that performance
critical objects should avoid the objc interface/language from the
start. I have invested much time in this, and proven it in multiple
real world cases (not small projects, but complex real programs that
required much time to change), and provided average real world results
in my previous messages. I believe everyone involved agrees/knows that
the speed difference is more than messaging.
J
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
