Re: Carbon vs Cocoa arguments
Re: Carbon vs Cocoa arguments
- Subject: Re: Carbon vs Cocoa arguments
- From: Izidor Jerebic <email@hidden>
- Date: Thu, 10 Oct 2002 15:17:28 +0200
On Thursday, Oct 10, 2002, at 12:51 Europe/Ljubljana, Eugene Lee wrote:
On Thu, Oct 10, 2002 at 10:48:07AM +0200, Izidor Jerebic wrote:
:
: On Tuesday, Oct 8, 2002, at 23:48 Europe/Ljubljana, Scott Corliss
wrote:
: >
: >This actually goes against what you're trying to prove, but might
give
: >you a little different viewpoint on Carbon.
: >
: >http://www.unsanity.org/archives/000024.php
:
: It naturally depends on what you do, but for developing a normal
: application with GUI, there is simply no way Carbon can be compared
to
: Cocoa. It is much easier and faster to develop such an application in
: Cocoa with less bugs. Just compare source examples from Apple for
: somehow similar apps - TextEdit in Cocoa and SimpleText in Carbon.
And
: then see the Sketch in Cocoa for example of drawing app. If these
: examples won't convince you, well, there's Apple's recommendation to
: develop new apps in Cocoa, which they adhere to (everything new is
: Cocoa).
These are RAD-type arguments to be made to developers. I'd like to see
more discussion on performance that is more visible to the end user.
The section that I found most interesting was this one:
Cocoa is generally SLOWER than Carbon, despite what most public
thinks. (When a Carbon app wants to call a function in itself,
it jumps directly to the function address; when Cocoa app wants
to do the same, it goes through a single (ok, there are a few
variations of it) function called objc_msgSend which finds the
correct address and jumps to there. This means each time a Cocoa
method calls another Cocoa method there's 16 to 80 instructions
overhead compared to Carbon. A true bottleneck, however it is
not a design flaw but rather a decision that makes objc quite
flexible to make it achieve what it needs to).
Now, this is really really misleading...
First, there is no such thing as "Cocoa method". Applications that use
Cocoa are normally written in Objective-C, but speed-critical parts of
Cocoa app may be written in C, C++, assembler, or anything else you
want to use for that.
Second, end-user in principle cannot distinguish Carbon from Cocoa app
(also because applications may have mixed widgets, custom widgets,
etc.). But well-written Carbon app may take so much more resources to
implement what Cocoa gives for free or much easier that management
decides it is not worth it - in that case one may spot badly written
Carbon apps (it seems that they are in majority, though).
And, finally, speed is the result of good design and optimizations, not
the API you work with. Speed-critical sections of your program are
typically implemented by custom code, which does the job in fastest
possible way given the parameters of your application. And since
putting together an application is faster and less buggier in Cocoa
(and uses sound OO principles implicitly), there remains more time for
optimizations. So using the same amount of resources (time, people),
Cocoa app is supposed to be faster and less buggy and better optimized,
because you spend less time on non-essential things.
izidor
P.S. As for Cocoa application speed: you can do your Cocoa application
about panel with custom assembler code that writes directly to video
memory for maximum performance so it appears on screen extremely fast
(just in case somebody misses the point: this is a joke to show how
performance can be utterly pointless for some parts of your
application).
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.