[interactive_civilian]

This cross-posted from the ArsTechnica Mac forum. I'm posting it here because I thought this my be a good place for info on this.

It is a spin-off of this BF thread about OS X and gaming. Pharsyde and I seem to be having some confusion about the merits of Carbon and Cocoa as far as performance are concerned.

Originally posted by Pharsyde:
<STRONG>One will give you access to both 9x and 10 but takes a performance hit relative to the other 10 only language.</STRONG>

I asked for evidence, and

Originally posted by Pharsyde:
<STRONG>Honestly, I have no hard proof but everything I hear keeps saying that Cocoa is the superior of the two. I think performance wise, cocoa will be superior to carbon by virtue of not having to span two different os's....</STRONG>

Now, I can see how this could seem to be the case, but to me it doesn't quite make sense. Carbon is more of an OS X native API ported to work w/ the classic MacOS using the CarbonLib extension, right? If so, then it seems to me that it shouldn't, by default, take a performance hit as compared to the other OS X native API , Cocoa. It seems to me that the real issue that would decide performance is the quality of the code rather than which API is used.

So, what do you all think? Will the choice of API alone have an effect on performance, or can a well written Carbon app perform just as well as a well written Cocoa app?

I took a look around the net, but couldn't find anything about performance, which leads me to believe that there is little or no difference in performance by default, and performance issues will depend on the quality of the code. The closest I could find was this post in response to this article on O'Reilly, and the post seems to say that for those writing games, and especially for those writing for multiple platforms, Carbon would be the more advantageous API.

Now, I (think I) understand the differences between Carbon and Cocoa as far as features are concerned, but is there necessarily any difference in performance?

I look forward to your responses. Please enlighten me. Cheers.

[yukon]

from what I can tell, "a well written cocoa app is equal to a well written carbon app".

although, it seems programming for cocoa is much easier, where carbon is much trickier. This makes it easy to make a well written cocoa app, but easy to make a screwed up carbon app. The finder, for example, is a "badly written carbon application", and rewriting it in cocoa will put a higher focus on its optimization.

also, way back in the land of dp4, i heard something about cocoa having multithreading where carbon would not. a lot of that type of thing was the norm during the dp4 release "will there still be creator/type codes?", "will my mouse work?, "are there resource forks?", and "33000 files???" etc, so im really not sure on that one.

[parallax]

Aye, from what I know, yukon is correct. Both are pretty "native" to Mac OS X, so the only difference _should_ be how easy it is to code it well.

[Angus_D]

In theory I guess Carbon should actually be faster, because Obj-C defers lots of things to runtime rather than compile-time.

[Millennium]

If you can qrite very good, tight Carbon code, then it will run slightly faster than the same app, written in Cocoa. You generally won't notice this difference, though, unless you're performing hundreds of CPU-intensive tasks per run, the difference is that slight.

Of course, a badly-written app in either API will work poorly. However, it's more difficult to write a program badly in Cocoa, simply because it does more of the work for you.

In the end, however, it really doesn't matter, because Carbon and Cocoa are both meant to deal only with interface-related tasks. For most CPU-intensive stuff you won't be calling either one; you'll be using one of the other API's (OpenGL, QuickTime, or etc.) or your own code. So for all practical purposes, the runtime speed difference is negligible.

Given this, I'd say your best bet would be to go with whichever API will get you up and running faster. For new projects, that will probably be Cocoa. For ports of older code, it's more likely to be Carbon (simply because it won't take a total rewrite to get it ready). Likewise, if you're used to procedural code, you'll probably find Carbon to be easier (though in that case I also suggest you work on learning OOP unless you have some ideological objection to the stuff ).

[interactive_civilian]

Just thought I'd share this little tidbit...it pretty much sums everything up (well, for me at least). KD5MDK over at ArsTechnica managed to dig this up...

Carbon vs. Cocoa. Carbon and Cococa are two APIs that developers can use to write applications for OS X. Cocoa is based on the OpenStep APIs; Carbon is based on the MacOS APIs. Cocoa is object-oriented, Carbon is procedural. Both Carbon and Cocoa are layered on top of CoreServices -- you can write a slow MacOS X application in either Carbon or Cocoa. You can write a fast MacOS X application in either Carbon or Cocoa; people touting one API or the other for performance reasons are misguided.

This is from this letter from the president of Ambrosia Software.

Thanks for the responses, everyone.

[edit]W00t! Finally hit the "member" mark...well, for the second time since my original account here was accidentally deleted.

[ 06-27-2001: Message edited by: interactive_civilian ]

[Apocalypse]

I recently read an article which discussed the differences between HFS+ and UFS file systems for OS X and I think that this might have some relationship to what is being discussed here.

Since the HFS+ file system interprets ":" as sub-directories and OS X uses "/" as sub-directories the Darwin layer must perform a translation operation for each file access. In UFS it doesn't so you could, theoretically, get less over-head.

This applies to our discussion in the way that Classic and Carbon are expecting the ":" symbol for sub-directories. As is such, the OS has to perform yet another translation operation (either in the carbon wrapper, LaunchCFMApp, or in the classic environment) where cocoa is expecting "/" and, thus, requires no more translations.

As simply an intellectual curiosity, does anyone think that this might make cocoa noticeably faster for highly file system intensive applications?

Just throwing in my ideas,
Jeff.

[Kickaha]

I seriously doubt it.

The file systems do not, as far as I've ever seen, have an explicit character that is used for directory differentiation. Instead, the UI (GUI, CLI, etc) handle that, and a file system calls are what convert the paths including those characters into file level descriptions of nodes, B-trees, etc, which the file system actually uses.

For instance, I use the Terminal under MacOS X on HFS+ drives all the time, and the delimiter is still '/', not ':'.

The files certainly aren't laid out using the delimiters, they're laid out in an abstract tree format. The delimiters are arbitrary.

[Millennium]

Besides which, translating a single character is extremely fast, taking no more than a hanfdul of CPU operations. Even at current PPC speeds, a human wouldn't be able to notice the difference unless thousands of translations were taking place, and even the difference would only be a fraction of a second in all but the most extreme circumstances. So there's no real harm in keeping it there.