mikeash.com pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html comments

mikeash - 2010-10-09 00:18:32

Sat, 09 Oct 2010 00:18:32 GMT

I can certainly see how it's a little harder for you to fill in the blank, but you can google for it and solve it without much trouble. If it were a question that a non-native speaker simply couldn't answer at all that would be one thing, but as it is, it just makes it slightly harder.

Your #define is amusing. Probably a bad idea, sadly. Although Apple has not been above the occasional #define to fix misspellings in their public APIs.

Joan - 2010-10-08 09:56:47

Fri, 08 Oct 2010 09:56:47 GMT

Mike,

Well, that was my point with the "humour" word thing. I certainly could assume the right spelling before searching but I *had* to google it to know for sure. I am not English native, English is my fourth language actually, and I learned the little I know in a non-English speaking country where only British spelling was taught. But yes, you are right that anyone should be able to solve that response challenge after all, if she/he is able to write some English. I think I should #define UIColour UIColor to avoid compiler errors in my code (sorry, just joking).

Thanks and keep with your excellent blog which definitely has taught me a lot.

mikeash - 2010-09-29 16:27:46

Wed, 29 Sep 2010 16:27:46 GMT

Are there actually people in the world who are sufficiently literate enough in English to be able to make an intelligent post to this site, but who are incapable of googling for "humour american spelling"?

Joan - 2010-09-29 10:08:21

Wed, 29 Sep 2010 10:08:21 GMT

I do not know what percentage of CF are implemented in ObjC or using the Cocoa apis. What I found is that if you decide to toll-brige among them then you should expect penalties only if you do so from Cocoa to CF, not the opposite, but still using only pure CF calls is faster than their Cocoa equivalents. This is what I found:

Fastest: CFArray accessed with CFArrayGetValueAtIndex
Faster: CFArray accessed with -objectAtIndex
Reference: NSArray accessed with -objectAtIndex
Slower: NSArray accessed with CFArrayGetValueAtIndex

This is consistent among several devices and OS, although actual differences may vary.

Joan Lluch-Zorrilla

btw. Just let me point out that some of your site challege-response questions are not fair for non US people or to whom do not have English as their primary language (specially US English). Consither this one: "Type the word "humour", but with American spelling". Definitely that question can not be solved in a fair way for all humans.

Uli Kusterer - 2010-04-17 15:14:59

Sat, 17 Apr 2010 15:14:59 GMT

Folks, this whole discussion is pointless regarding the iPhone: If you look at the Darwin sources, you'll see that the iPhone's CoreFoundation classes are actually implemented in ObjC.

That's right: CFArray and the likes are ObjC classes on the iPhone.

Stuart Carnie - 2010-01-26 07:22:25

Tue, 26 Jan 2010 07:22:25 GMT

Indeed, the ObjC / CF is pretty much a non-issue on newer hardware. Certainly not worth the effort.

I was incredibly impressed by the IMP call on the Cortex CPU...wow.

I've implemented the enumerator code before to use the for/in syntax (a simple state machine). It would be nice if Apple introduced a 'yield' keyword like other languages, to save us having to write the state machine code all the time. Regardless, it's fairly easy to write and the performance pretty close to the metal.

mikeash - 2010-01-25 22:03:40

Mon, 25 Jan 2010 22:03:40 GMT

Very nice. I like that you were able to benchmark two different types of hardware too.

It looks like the difference between the ObjC and CF calls is approximately equal to the cost of a message send, which is what I'd expect to see.

Note that in the particular case of iterating over stuff, the fast enumeration for/in syntax is almost certain to be the winner. It uses ObjC messaging to talk to the object, but returns objects in bulk and can return interior pointers, which means that the number of calls/messages will be much smaller than the number of objects in the array.

Of course, there's a lot more stuff out there than just iteration, and no equivalent to fast enumeration for the rest.

Stuart Carnie - 2010-01-25 06:07:53

Mon, 25 Jan 2010 06:07:53 GMT

G'Day again Mike - ended up adding the benchmarks as you suggested. I posted some information on my blog, and the results are certainly interesting - tested 2nd and 3rd gen iPhones. My results show the IMP call is faster than the C++ virtual method call, as you originally had expected.

Blog post here: http://bit.ly/5pxjgk

Stuart Carnie - 2010-01-24 18:33:23

Sun, 24 Jan 2010 18:33:23 GMT

Great idea, I'll take a look at the test suite and add an additional comparison between equivalent Obj-C / CF. I'll post the results here when I give it a go.

mikeash - 2010-01-24 17:43:17

Sun, 24 Jan 2010 17:43:17 GMT

This stuff is definitely still interesting and good to know even if you shouldn't be thinking about it all the time. Perhaps you could add some CF benchmarks to this stuff:

http://mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-iphone-edition.html

Stuart Carnie - 2010-01-24 07:38:15

Sun, 24 Jan 2010 07:38:15 GMT

Absolutely @mikeash - how far our hardware has come. I'm not one to prematurely optimize code (especially if I don't have numbers to back it up), but I thought it an interesting micro-benchmark exercise. I'm a firm believer that understanding the mechanics of your "hardware" helps you to make it perform better.

Cheers and thanks for the informative post,

Stu

mikeash - 2010-01-23 23:37:50

Sat, 23 Jan 2010 23:37:50 GMT

The macro looks up the appropriate isa for the given CFType (which I believe is a single array lookup) and then compares it with the object's isa, so the overhead is basically two loads from memory. Not much. Using CF functions is faster than ObjC methods if the object is a "real" CF object; obviously it's slower if it's actually a pure Objective-C class and the call has to be bounced back to that side. Whether the overhead matters is another question entirely. As with any programming task, favor writing clear code over writing fast code unless speed is proven to matter in the real world. Just because you're on an iPhone doesn't make objc_msgSend automatically horrible. Remember that NeXTSTEP originally ran on 25MHz 68080s, a CPU roughly 10x slower than the iPhone's ARM, and it did everything with Objective-C.

Stuart Carnie - 2010-01-23 22:14:47

Sat, 23 Jan 2010 22:14:47 GMT

What's the overhead of the macro CF_OBJC_FUNCDISPATCH0? I would have expected calling the CF C functions a little more efficient, particularly on a resource constrained device like the iPhone.

Perhaps I'll do a few micro-benchmarks and publish the results on my blog (which is in serious need of updating anyhow). My thought was that when building a reusable iPhone framework using CF/NS classes, one would be better off using the CF* equivalents.

Cheers,

Stu

mikeash - 2010-01-23 02:44:47

Sat, 23 Jan 2010 02:44:47 GMT

I don't consider either of those to be bridging in the sense used by CoreFoundation. If you write an Objective-C class with a C wrapper, that's just an Objective-C class with a C wrapper. If you implement the class in C, that's just a C library with an Objective-C wrapper which then has a C wrapper too. Not to say that it isn't sometimes useful to do that, it's just not bridging.

alastair - 2010-01-22 22:13:54

Fri, 22 Jan 2010 22:13:54 GMT

You can also optimise what Ken suggests by putting the implementation code into a set of C implementation functions, calling those from the ObjC methods, and calling them directly from the C API when you know that the object you've been given is of the class you expect.

Obviously this kind of thing is only for use in extreme cases :-)

ken - 2010-01-22 21:35:39

Fri, 22 Jan 2010 21:35:39 GMT

On creating bridged classes, you sort of can, you just make the ObjC the primitive and the C side a wrapper for ObjC method dispatch.

From the outside, it looks the same. There's a CF-level function interface, there's an ObjC class, the types are interchangeable, and you can subclass the ObjC class and pass it to the the C function interface.

Why would you do this? Well, there isn't a lot of reason, but sometimes people have files that they want to be pure C.