CoreFoundation vs Foundation

In a technical sense, yes, it is faster, for exactly that reason.

In a practical sense, no, it's not faster. For one thing, the speed difference is tiny. We're talking milliseconds saved over the life of the entire process.

The savings might be bigger on the iPhone, but it's still pretty much the tiniest speed gain you can get. Your time is much better spent profiling your app in Instruments and going where it tells you and ironing out the hot spots in your own code.

And that's where Foundation becomes faster: Your time.

Code that uses Foundation's autorelease feature whenever feasible saves you a lot of time and headaches by avoiding easily-avoidable memory leaks (namely, forgetting to write or failing to reach release messages). CF does not have autorelease, so you have to remember to explicitly CFRelease everything you create or copy with it—and when you forget or fail to reach that code (and I do mean when—I speak from experience), you will spend much more time hunting down the memory leak. The static analyzer helps, but it will never be able to catch everything.

(You technically can autorelease CF objects, but the code to do so is terribly ugly and you're only watering down your already-minuscule speed gain.)

So, stick to Foundation as much as possible. Don't go overboard with the autorelease; even in pure Cocoa, there are still times when explicitly releasing objects is warranted (mostly tight loops), and this goes double for Cocoa Touch (since iOS will kill your app if you allocate too much memory, so you'll want to release big objects like images as soon as possible). But usually, autorelease saves you far more time than CF will ever save your users.

The non-time-related reason is that Objective-C code, with argument names (from the message selector) mixed in with values, is far easier to read than C function-based code. This may not make your work go any faster, but it certainly makes it more fun.

When I use CF objects, I alway use a C++ wrapper whose destructor takes care of the CFRelease, and which also has copy constructors and such that do the right thing. Remembering to put a CF object in such a wrapper as soon as it's created is not any harder than remembering to autorelease Foundation objects, at least for me. But I agree that any time difference is probably minimal, and that one should let a profiler guide one's optimization efforts.

JWWalker 2010-09-23 06:03:57

I am looking to convert a ton of data from a custom structured text format in to true objects for the iPhone to use. I am however going to mark this as answered.

jcstanton 2010-09-23 12:15:42

@JWWalker: If you're going to wrap a CoreFoundation object, why not just wrap it in Objective-C? In fact, classes with CF analogues are most often just wrappers around the CF class anyway. (For example, `NSMutableDictionary` is a class cluster that often returns an object whose actual class is `NSCFDictionary`, which is basically just an ObjC class that uses a CFDictionary as its backing store.)

mipadi 2010-09-23 15:33:30

Well in my case, the idea would be, dont use cocoa, avoid throwing around messages to gain some speed.

jcstanton 2010-09-23 16:22:31

jcstanton: Write it in Cocoa first. Then profile it. I can almost guarantee that Objective-C messaging (`objc_msgSend` and its siblings) will not be the most expensive thing the profile shows. And if it is, it generally means that you're sending excessive numbers of messages in the first place, and making excessive numbers of function calls instead will not solve your real problem.

Peter Hosey 2010-09-23 16:51:13

ansaurus

tags:

views:

answers:

CoreFoundation vs Foundation

related questions