Re: Carbon vs Cocoa arguments
Re: Carbon vs Cocoa arguments
- Subject: Re: Carbon vs Cocoa arguments
- From: Ryan McGann <email@hidden>
- Date: Thu, 10 Oct 2002 21:44:13 -0700
>
> Cocoa is generally SLOWER than Carbon,
>
>
This is *NOT* true.
>
As you point out, this depends on the situation. I can certainly write
a Carbon application that is much faster than its Cocoa counterpoint.
But this is due in part to many things, including the Obj-C runtime.
>
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 ;)
This depends on the programmer and the application. A lazy programmer
will take the easy road, which is to use NSNumer's stored in an
NSArray. Very few applications are doing heavy number crunching. IMHO,
a faceless applicaiton like a command line tool should be doing that
stuff and not wasting cycles in the UI. But when an app is doing number
crunching, it's usually without the aid of the operating systemit's
custom code that's portable and as fast as possible. So in the general
case (which is a typical application showing windows and accepting user
feedback 95% of the time) Cocoa can very well be slower than Carbon.
>
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)
The Finder has many issues with it. I can make a Cocoa applicaiton
however that's just as slow as the Finder, if not slower. Much of the
Finder's problems stem from problems that Cocoa has as well: the UI is
_not_ thread safe for the most part. The Finder was sped up in Jaguar
from spawning new threads, which was possible due to improved threading
capabilities in Jaguar (much more of Jaguar is thread-safe in Carbon
and Cocoa). Using the Finder as an example of Carbon's speed is like
using the sloth-like Mail.app (or worse, ProjectBuilder, the slowest
IDE ever made) as an example of Cocoa's speed.
Cocoa developers have a slight knee-jerk reaction to Carbon, shying
away from it as much as possible. Carbon is still very viable, and has
to be if the Mac will be a major player in the PC market considering no
major commerical applications have been written in Cocoa yet. Carbon
and Cocoa use eachother, but many things still exist in only one
framework (disclosure button, clock control, checkbox group box, to
name a few, are all missing from Cocoa still).
The point is, use whatever you want. Cocoa uses Carbon but is easier to
program for. Carbon is backwards compatible for those 80% of the Mac
users still using OS 9. And in the future, they will merge further and
become dependant on the other, making stupid arguments like this moot.
Ryan
_______________________________________________
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.