2

I noticed with with the latest update to XCode (4.6), I was given a warning about a couple of lines in JSONKit.m. Specifically, lines that set the class of an object:

dictionary->isa = _JKDictionaryClass;

These are marked as deprecated with a note that the preferred method was to use object_setClass():

object_setClass(dictionary, _JKDictionaryClass);

When I asked why it was preferred to simply silence the warning, the response was:

Everything works fine even if new Xcode version complains, I don't want to :
1) test each project where i use JSONKit to check if everything goes fine after object_setClass()
2) loose cpu cycles, which is the reason why i use JSONKit over NSJSONSerialization for example. My current application parses json files that weights 600K-1M

Just how much of a performance hit are we talking about here?

NOTE:

I am more interested in

dictionary->isa = _JKDictionaryClass vs object_setClass()

than JSONKit vs NSJSONSerialization.

jscs
  • 63,694
  • 13
  • 151
  • 195
Mike D
  • 4,938
  • 6
  • 43
  • 99
  • The function call will probably have a small overhead - but would you care about those few CPU cycles? Really, this isn't going to be called continuously within a loop... –  Feb 20 '13 at 17:40
  • @H2CO3 No, and I have not seen a performance hit. I am just trying to understand the reasoning better. But I am also not not parsing JSON strings that big. – Mike D Feb 20 '13 at 17:42
  • 1
    The reasoning is that function calls always have some overhead: the arguments should be pushed onto the stack (and caller-saved registers too), then the instruction pointer should be updated, then all this should be done in reverse when the function returns. It's generally more computationally expensive than simply dereferencing a pointer (which can be as simple as `mov [dest] [src]`. –  Feb 20 '13 at 17:45
  • @H2CO3 Thanks. I figured it was that simple. – Mike D Feb 20 '13 at 18:06
  • 2
    @H2CO3, as the author of JSONKit, I'd just like to point out that this bit of code is, in fact, called continuously within a loop- it's called every time a `NSDictionary` needs to be created for a bit of parsed JSON. It is called *so often* that there was a considerable performance win in writing a custom `NSDictionary` compatible class. – johne Feb 25 '13 at 13:20
  • 1
    @johne given the improvements to clang ( and obj-c in the mean time ), do you still think this is the case? my guess would be that adding the warning came after some changes/improvements to that specific area. If you still have the tests for this just point me to them and i'll be happy to run them – Mihai Timar Jan 27 '14 at 09:37

2 Answers2

10

The reasoning has nothing to do with a performance hit, and never did. The definition of an object as having an isa pointer is an implementation detail, and has been as much since at least Objective-C 2.0 (and conceptually has been for much longer). The Clang compiler folks and Apple, especially the people involved in optimizing the runtime, would like nothing better than to be able to define an object as having whatever internal structure is fastest instead of always maintaining this isa field. The fact that isa exists, the fact that it exists at the start of every object, and that the isa is simply a Class pointer, has always theoretically been subject to change. It hasn't changed up to this point more because of the compatibility break doing so would cause than anything else.

Also, the performance characteristics of object_setClass versus object->isa = blah are a bit of a joke. The CPU is liable to, at the hardware level, optimize out the overhead of the function call long before it ever affects your code. If you're worrying about the number of cycles involved in pushq %rbp; movq %rsp, %rbp; movq %rsi, (%rdi); popq %rbp; ret, you're not in the Objective-C problem domain anymore - you should be working at the C or assembly language levels already if your code is sensitive to a different made by five instructions.

And even all of that aside, there are few good reasons to be setting the class of an object in this fashion to begin with. Why in the world are you doing this, and how is it helpful to you?

Finally, I might add that the Clang team has better things to do than add warnings purely for the sake of dealing with this kind of "performance" "issue". Almost all warnings (not all, but most) mean that you're doing something wrong, even if it happens to work at the moment in the cases you're testing. This code would already break for any object that uses tagged pointers. This is what Xcode is trying to tell you.

Edit: It's been pointed out to me that the question wasn't about the reason for the warning itself, but rather the particular performance characteristics of the function in question. As I mentioned in my answer, the performance hit is so small that if it were relevant to your code, you shouldn't be using Objective-C in the first place. My apologies for misunderstanding the original question.

Gwynne Raskind
  • 1,164
  • 10
  • 11
  • Thank you, but I know why Xcode is displaying an error. It was a matter of understanding if using `object_setClass()` was that much of a performance hit. – Mike D Feb 20 '13 at 19:44
  • 1
    Short answer, no, it's not :) Modern CPUs would tend to live-inline such a tiny function if the compiler hadn't done it already, and between branch prediction and instruction pipelining, the lost time is extremely tiny. – Gwynne Raskind Feb 20 '13 at 19:48
  • @GwynneRaskind still, there *can* be an overhead just for the reason I explained - it doesn't mean there **is** nor that it's significant (you know if someone hates premature optimization, that's me), but still. –  Feb 21 '13 at 05:42
3

The reasoning is that function calls always have some overhead: the arguments should be pushed onto the stack (and caller-saved registers too), then the instruction pointer should be updated, then all this should be done in reverse when the function returns. It's generally more computationally expensive than simply dereferencing a pointer (which can be as simple as mov [dest] [src].