|
February 13, 2003
Carbon vs Cocoa: The Speed Issue
This will be a short post but I've yet to ever see a fast Cocoa application especially when compared to a carbon one. I mean, *ever*. Let's make a short list. Cocoa on left, much faster carbon (or C) on right. Mail.app vs. Entourage, Eudora, PowerMail. Especially when dealing with 5000+ messages in one mailbox. OmniWeb vs Chimera, IE, Mozilla, Safari. OmniWeb is so very slow. Noticed how I put Chimera and Safari in the Carbon/C field. Both use Carbon and or C to render items. Just a few things (like the GUI) are Cocoa. I think Safari has a bit more Cocoa code in it but David Hyatt is working on it and causes an exception. iPhoto vs Coffee Machine. iPhoto has been slammed over and over and over for it's slow speed especially when resizing. iMovie 3 vs iMovie 2. Yeah, iMovie was upgraded to Cocoa recently and look what happened. ProjectBuilder text editing vs BBEdit, CW IDE. 'Nuff said. PB's editing is so slow that it has to be a default exclusion for Silk. I guess that's what happens when you look at each typed character multiple times. Path Finder (SNAX 2.0) vs Finder (in 10.2). Yeah, Path finder is much slower than the Finder. That's kind of depressing. I don't mention many third party applications because I don't use many third party cocoa applications. It's just the way things fall. And yes, Cocoa applications usually are prettier than Carbon applications. But that could be because the Carbon applications you see are made with the devil-spawn known as PowerPlant and not lovely nibs that use ATSUI and junk like that. I've still yet to see a super fast Cocoa application. Please point one out and mention the carbon/c alternative. I've seen a bunch of fast (properly written) Carbon apps that use RAEL/CarbonEvents instead of WNE/Polling. David can attest to this I believe.   Posted by rosyna at February 13, 2003 06:17 PMTrackback Pings: TrackBack URL for this entry: Listed below are links to weblogs that reference Carbon vs Cocoa: The Speed Issue: Linkdump from ext|circ Tracked on February 14, 2003 7:53 AM To Cocoa or not to Cocoa from The City of Gray Tracked on February 15, 2003 8:51 AM Related:
Comments
ooooh burnnnnn....... Yeah, you're right, cocoa is a bit slower. But every carbon app i have seen is ghetto. I'm sure its because its just ported from an Os 9 app, but in my experience, a cocoa application just looks nicer. Look at snak or bbedit, blegh. Those buttons are for the birds. It just looks horrible. Yes, its not just about looks, but it doesn't hurt ;) Cocoa devs will get better and so will the APIs, and so will the hardware. This is a natural progression, something i'm sure i dont have to tell you. Posted by: seven5 on February 13, 2003 6:35 PMNote that all the things on the left (except OmniWeb) are Apple apps. Good developers profile to figure out what's slow, and then speed that up, rather than making baseless generalizations about things that might cause slowness. Premature optimization is the root of all evil. Posted by: Aaron Swartz on February 13, 2003 6:45 PMI hate to mention this, but Transmit 2.0 seems slower than 1.7.3b... that's another Cocoa slower than Carbon. Posted by: Etan on February 13, 2003 6:55 PMC++ code is faster than Objective C since it doesn't have the extra overhead of runtime method lookups & type checking. C++ vtables are much more efficient and are only used for virtual methods, so the compiler can use direct function calls in many cases. Also, most Carbon apps are written in CodeWarrior, which generates better code than gcc. Posted by: Mike Cohen on February 13, 2003 7:40 PMIndeed, but Cocoa applications (except most of the ones Apple makes) look so much nicer than Carbon apps. Especially the Carbon apps that were ported from Classic without much thought to making the interface conform to the AHIG. Posted by: Adam Atlas on February 13, 2003 7:52 PMCoffee Machine? What app is that? First time I heard of it, been using iView instead of iPhoto. Posted by: oeyvind on February 13, 2003 7:57 PMI've seen some rather nice looking Carbon apps (in fact, even though CW uses PowerPlant, I would say that it looks rather nice, mostly at least =p). In fact, from the Carbon-Dev list, I would say to expect quite a few nice looking Carbon apps in the near future too. Personally, I don't really care if an app is Carbon or Cocoa - what I do care about is how well it works. And generally both kinds work just fine. But the Cocoa ones do tend to be slower, no doubt about it. And any programmer that tells you that Cocoa doesn't have it's overhead is diluding themselves (for that matter, any one who tells you that X is the end all and be all is diluding themselves). Just remember, someday Cocoa will be built on top of Carbon. If you don't believe me, then come up with a better solution to getting Carbon & Cocoa to work together seamlessly. Posted by: Rincewind on February 13, 2003 8:29 PMHmm.. When I said 'X' before, I meant 'solution X' not Mac OS X. Mac OS X is about as close to the end all and be all as something can get without one diluding themselves =). Posted by: Rincewind on February 13, 2003 8:30 PMRaw speed and perceived speed are two different things. So to take the example of Mail vs. Entourage: Mail.app might be slower at churning through a folder with 5,000 messages in it, but it actually feels more responsive in day-to-day use. In general I just find that Cocoa apps respond more like I want them to... they just "feel" better. So I'm not talking about raw speed here; I'm talking about responsiveness. A cocoa app like Mail just seems snappier to me than Entourage. Another classic example: Safari vs. Internet Explorer. Not even talking about the rendering engine here (the C/C++ part); the way the Safari buttons and windows "feel" (all Objective-C/Cocoa) is just way better in my book. Posted by: Wincent Colaiuta on February 13, 2003 9:58 PMListen, I was a member of the Carbon team at Apple, and I'm here to tell you, it doesn't matter whether or not you use Carbon or Cocoa -- you can design halfassed performance drains in either of them. The worst and also the most common apps (performance and UI) on the Mac OS X platform are Carbon: consider Internet Explorer, the Finder. Also think about iTunes, a pure Carbon app: is it really particularly speedy? I find it pretty sluggish. Either environment will perform just fine if you properly design and performance-tune the application. You can design dreck in Carbon much easier than you can in Cocoa (witness IE), but you can shoot yourself in the foot quite happily with either of them. Some other notes: - Mail.app is perfectly responsive (especially compared to (say) Entourage) -- if you don't use it's antiquated search facilities. This is not a Cocoa issue, but a problem of bad data structure design. It uses a primitive indexing scheme on top of Unix mbox files. (If only they'd use VTwin... I swear, CyberDog is still the mail client to beat for searching.) - Also check out some of the OmniGroup's apps, like OmniGraffle or OmniOutliner. These are pretty speedy, IIRC, and all of them are Cocoa apps. (OmniWeb's HTML rendering is slow mainly because OmniHTML abuses the Cocoa view hierarchy, much like IE is abusing all of Carbon.) Posted by: Carbon Loving Dude on February 13, 2003 10:57 PMif i have to take a speed hit on transmit to get the features they gave me with 2.0, then SO BE IT. Transmit 1.x was a pathetic ftp client, but so was EVERY other ftp client out there for the mac. Coming to the mac world last January (2002) i was quite disgusted. But now that transmit has gone Cocoa and used libNCFTP, its great, nice features, and i think it IS faster personally, and it has ALL the features of a good ftp client, it just needs to tighten them up. This app also uses a C backend like safari and chimera........ Posted by: seven5 on February 13, 2003 11:08 PMTo Carbon Loving Dude, who claimed to have worked at Apple: Carbon can use NIBs, so the fact that Safari uses NIB files for the bookmarks management doesn't reveal anything in and out of itself. However, I'll grant you that the UI does use Cocoa. But the NIBs aren't the deciding factor. Likewise, Safari/WebCore's KWQ does wrap parts of Qt into Cocoa, but the KHTML layout engine itself has nothing to do with Objective-C -- it is basically as close to Carbon as you can be with a codebase first established on GNU/Linux. It's the same as with Gecko in Chimera -- it's wrapped in a pretty Cocoa wrapper, but it's still C/C++ and thusly uses Carbon routines. Posted by: Lauri K on February 14, 2003 3:06 AMI've found that I prefer the cocoa apps over carbon. All the carbon apps I use (office v.X, itunes) feel less responsive than the cocoa apps I use. It's to the point where I go out of my way to find cocoa alternatives. In other words, I agree with Wincent above: it's definitely about the perceived differences for me. As long as it feels faster, I'm all for it, and, for the most part, it feels to me like the carbon apps are slower. If I had a faster machine, I'm guessing it would be a moot point. Posted by: michael on February 14, 2003 3:13 AMI also prefer Cocoa apps... I'm only on a dual 500 with a gig of RAM and Quartz Extreme, but everything seems nice and zippy! Cocoa apps just seem to ~feel~ more native to the new OS than Carbon apps do, maybe because Carbon apps are made also to run in the Classic with carbonlib? I dunno, Apple says using either or is a true native OS X app... And Rosyne - where to find this Coffee Machine app? iPhoto's great (yip, I'm a fan of all the iApps) but something better/fater may pursuade me! Can't ind it on VersionTracker anyway... Posted by: Dan on February 14, 2003 8:37 AMJust to throw in my two cents: Has anyone been able to locate this Coffee Machine app rosyna mentioned? A Google search is just about worthless, since a million people seem to have to post pictures of their coffee brewers online... Posted by: chris on February 14, 2003 10:28 AMCoffee Machine was a joke... It means I can brew Coffee that I don't drink faster than I can launch and resize an iPhoto or iCal window. Posted by: Rosyna on February 14, 2003 11:41 AMPath Finder is within days of an update. That info straight from the author. Posted by: Dave on February 14, 2003 12:32 PMOmniOutliner is great, but slow like a dog. I couldn't care less if it's Carbon or Cocoa, just make it *fast*. I use OS X since 10.0, since the functionality (BSD inside...) made the switch a no-brainer, but the speed of the whole system is still a disappointment, even with Jag/QE. Remember that's the system everyone was waiting for since it's so blazing fast due to the final goodbye to emulated 68k code and all.... Posted by: skab on February 14, 2003 4:44 PMI'd guess that Safari uses CoreGraphics and ATSUI. I doubt Safari uses anything inside of Carbon.framework. CoreGraphics isn't Carbon, regardless of the language of the API. Some of ATSUI is supported by Carbon, but some functions are not. Remember: Strictly speaking Carbon is the API that works on both OS X and OS 9. Carbon isn't "any C-based API on OS X", because that would include Mach and Unix, which is clearly absurd. Likewise, Cocoa applications make intensive use of a function objc_msg_send(), which is C, not an Objective-C method. That doesn't mean all Cocoa applications are Carbon applications. However... It's definitely a bit painful as an old-time NeXT developer seeing how pokey Cocoa apps can run on OS X, on my 500MHz iBook. Much slower than apps ran on the 400 MHz non-Athlon AMD that I used to run OpenStep on back in the late 90's. I think it'd be interesting to put a Carbon app that makes heavy use of CoreFoundation up against a Carbon app that uses other data structures, perhaps any provided by PowerPlant, or rolled at home. CFArray vs. ? CFString vs. ? The Cocoa frameworks make heavy use of CoreFoundation, so any inefficiencies in CF would strongly effect a Cocoa application. But a Carbon application might use CF less, and thus not be hampered, and thus perform better. I'm guessing that Carbon apps might use CF where necessary to interface with the APIs, but use other data structures and stuff the same as they did pre-CF. Or do people Carbonizing their applications go through and rip out their old datatypes and data structures and put in CoreFoundation code? If you've got some libraries of code you reuse, do you retrofit them to be all-CF, or do you just change them when necessary to convert to/from CF? Has anyone made that comparison? I'm curious. [My vote for slow Carbon app would be iTunes. It uses way too much CPU, compared to MP3 players on Windows. But I bet that slowdown is not in Carbon-oriented code, but in generic C/C++ code. Or maybe it's the OS at fault.] This article is an unbelievable troll, IMHO. Calling your comparisons unscientific would be a gross understatement. Your single-minded focus on the tools one uses to do a job suggests a lack of understanding of the things that make products what they are. I certainly hope for your sake that I am wrong about that and that you had simply inhaled from the bong too deeply while composing your post. :) For the record, I have used PowerPlant, straight Mac Toolbox/Carbon and Cocoa to deploy apps on the Mac, so I really don't have a particular drum to beat here. Perhaps an article explaining your haphazard prejudice would be good material for another post to your weblog. ;) Posted by: Kris Amico on February 16, 2003 4:44 AMwell troll or no.. the coffee machine joke is a pretty good one! Posted by: pete on February 18, 2003 1:21 AMhate to say this, but the latest version of Path Finder is WAY faster than previous builds on my DP867. Feels as fast as the finder to me, but is a hell of a lot more functional... Posted by: tersono on February 18, 2003 9:27 AMI'm not sure what all the yap is about. On pure performance it would appear that c/c++ carbon applications do have a slight advantage over Objective-C Cocoa applications. But this performance is purely at the code level and how much of it is experienced by the user is conjective. One thing is for sure, with the exception of the Quake III conversion, nearly ALL heavy processor usage 3D games are written in C/C++. Now clearly some of this has to do with ease of portage. But there has to be a point where the advantages of the 'easy' runtime routines are outweighed by the needs for the extra few frames a second. What's more worrying is that the majority of the Cocoa native classes can be optimised by re-writing them. See http://www.mulle-kybernetik.com/artikel/Optimization/opti-4.html for a full explanation. Its quite alarming. Posted by: Robert Leather on April 26, 2003 7:52 PMApologies for being a bit off topic here... but you all seem to really know what you are talking about... and I am a neophyte MAC user. I have a new powerbook which seemed SUPER fast when I got it... EXCEPT for the Help file for the basic system. It was fast at first... but within a month turned into a total slug whenever I submitted a search. Since I'm a new user I find I use it a lot... so this is really annoying. The only thing that had changed was that I had loaded in some other software (including Virtual PC which I had to have for one of my biz apps). Does anyone know why my Help file is so slow? And if it can be fixed? If so, please reply directly to me at sue@connectionsgroups.com (I already feel guilty about taking up this space on a personal issue) Thanks so much for your time! Sue :) Posted by: Sue Copening on June 19, 2003 10:51 AMNews Flash :: Cococa = Carbon! Cocoa is just a wrapper for Carbon methods. Which naturally makes it slower. Carbon apps generally look like crap cause idiots wrote them. I write in Carbon generally more than Cocoa and people can't tell the apps apart. This is a sign it was done right. (Except of course speed). Posted by: Martin Mroz on February 23, 2005 8:36 PM |