Re: NSPoint. The results. Look at that, Georg!
Re: NSPoint. The results. Look at that, Georg!
- Subject: Re: NSPoint. The results. Look at that, Georg!
- From: Pete Yandell <email@hidden>
- Date: Tue, 4 Mar 2003 01:59:13 +1100
- Resent-cc: email@hidden
- Resent-date: Tue, 4 Mar 2003 02:10:32 +1100
- Resent-from: Pete Yandell <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: Pascal Goguey <email@hidden>
Objective-C _is_ extremely inefficient compared to C++, at least for
the particular cases that you're discussing here!
One of the basic premises of the design of C++ was that C++ features
should add as little performance overhead to C as possible. In
particular, if a C++ feature is not being used then it should have no
impact on performance. I read a really good article about this a while
ago, but I can't remember where it was. *scratches head*
Objective-C does not follow this rule and does, in fact, add a bunch of
overhead to C in exchange for some useful features.
Looking at your two experiments:
1. The speed experiment
The data in memory looks exactly the same for both structs and classes
in C++, and method calls are resolved at compile time (discounting the
use of virtual methods.) In fact, from memory, the only difference
between a struct and class is that a struct has its members public by
default.
Your call to "set" is resolved by the compiler at compile time, is
inlined by the optimiser and ends up being exactly the same as your
code that manipulates the struct. Hence the identical times.
In objective-C, on the other hand, all methods are virtual. That means
that each call to "set" would have to be resolved at runtime...that's
an extra table lookup and function call each time around the loop.
I ran some tests on array sorting a while ago. Sorting 100,000 items
gave the following results:
Using C qsort to sort a C array of integers: 0.15 seconds
Using C qsort to sort a C array containing Objective-C objects of a
minimal integer class: 0.78 seconds
Using sortUsingFunction: on an NSMutableArray containing objects of a
minimal integer class: 0.60 seconds
So at best the overhead of objective-C more than quadruples the sorting
time. So is objective-C ridiculously slow? Well, for a complex data
structure it adds relatively little overhead. For a data structure as
simple as an integer or a point, on the other hand, a small overhead
can actually amount to a fair bit when you're processing large amounts
of data.
(Note that there are ways to further optimise the Objective-C version
of my sort by manually caching method lookups. The best time I can
manage is around 0.37 seconds. Interestingly doing a naive
sortUsingSelector: on an NSMutableArray of NSNumbers gives a huge 3.9
seconds!)
2.The size experiment
At a minimum, an objective-C object is going to have 4 bytes of
overhead on top of the size of the equivalent struct. This is to hold
the "isa" pointer which determines the class of the object. Adding 4
bytes to an 8 byte object is, of course, substantial overhead.
Try adding a virtual method to your C++ BPoint class and you'll find
that it'll grow 4 bytes as well. Now all objects of that class need a
pointer to the virtual function table.
The conclusion:
For simple data structures the overhead of objective-C objects compared
to simple C structs is quite large.
For larger and more complex objects, of course, the overhead of
objective-C is more than worth it for the advantages of dynamic method
dispatching, dynamic typing, etc.
I think the design decision to keep points, rectangles, etc. as structs
was a very sensible one.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.