Re: Carbon vs Cocoa arguments
Re: Carbon vs Cocoa arguments
- Subject: Re: Carbon vs Cocoa arguments
- From: Ondra Cada <email@hidden>
- Date: Thu, 10 Oct 2002 15:36:48 +0200
On Thursday, October 10, 2002, at 12:51 , Eugene Lee wrote:
Cocoa is generally SLOWER than Carbon,
This is *NOT* true.
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.
This is truth, *but*...
A true bottleneck
...it is far from true bottleneck. A bottleneck is not just a relatively
slow code; a bottleneck is a relatively slow code used in a place where it
harms. Message sending would become that in case you used it, eg. with
NSNumbers for a computation-intensive task -- say, fractals. Nobody does
that; it is why Objective C has the -C part.
Normally though the exact opposite is true: the much higher abstraction
level and easy-to-useness of ObjC with Cocoa libraries allows you to focus
on the problem, which tends to end with a better algorithm. The inevitable
result is that Cocoa apps tend to be actually *FASTER* than
Carbon-or-whatever-other-API apps, made with roughly comparable effort:
you lose some ticks here and there, but get O(n) instead of O(n*n) for
exchange ;)
From the practical experience side I guess the best support is
But for Apple's supposed flagship application, the Finder, to suffer
speedwise like it did until Jaguar, is NOT a ringing endorsement for
Carbon. While again - Workspace Manager ported fine to Mac OS X Server 1.
x (which was essentially NeXTStep 5.x)
You know, comparing the speed of function call vs. message send (which is
truthfully in average twice or thrice slower) is just as reasonable as
comparing the frequency of G4 and a Pentium, so far as its impact on the
application speed is concerned ;)
Cocoa suffers somehow in OSX (precisely: suffered in 10.0 and 10.1, haven'
t checked in 10.2) by substantial re-writing of its foundation (Foundation,
actually ;), whose new incarnation, split to Core and OO Foundation, is
(or, hopefully, was) considerably less effective than the original thing.
There are also some well-known issues with redrawing (mainly the terrible
redraw-a-rectangle-union-of-all-invalidated-rects howler). That all though
is a library implementation problem, far from a conceptual OOP problem.
Also it might be worth adding that
These are RAD-type arguments to be made to developers.
RAD-type arguments are *not* for developers, but for users. A developer is
happy developing (presumed it is paid well ;), so the idea of endless
optimization and fixing bugs does not look as too repulsive to him.
It is the user, OTOH, who wants
- a nice and stable application;
- reasonably featured;
- as soon as possible;
- to be upgraded reasonably often;
- with as little number of new bugs in a new release as possible.
All those factors are very very RADdy or, in Mac OS X, Cocoaish.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.