Re: Native Cocoa vs Java performance question
Re: Native Cocoa vs Java performance question
- Subject: Re: Native Cocoa vs Java performance question
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 12 Apr 2003 10:09:08 -0400
On Friday, Apr 11, 2003, at 17:30 US/Eastern, Sheehan Olver wrote:
Hmm, I was under the impression that CF* and NS* are
indistinguishable, i.e. they are bit-for-bit equivalent. If I was
correct, this would mean that the implementation of a CF Function
could poke right in to the data structure in a c-like manor as opposed
to just making message calls anyways. Of course, I may be wrong. I
agree with the rest of the message, but the point was that it was
working fine speed wise in java, and any architectural problem would
most likely affect both C and Objective-C.
The APIs are bit-for-bit equivalent, but that doesn't mean that
underlying implementation has to be. On the CF* side, it is possible
to create various permutations of CF* style objects that cannot be
created via the NS* APIs. From the other direction, you can subclass
the various class cluster objects and instances of your class still
work correctly-- something that could only be done if the NS* side of
the implementation continues to follow the OO rules as perpetuated by
the abstract superclass within the class cluster.
It appears from the exposed parts of the implementation that-- for the
most part-- the NS* objects are now implemented entirely by a private
NSCF* subclass. That is, the concrete class that implements the
behavior of an NSMutableDictionary is an NSCFMutableDictionary.
Now -- there isn't a 100% mapping between the NS* and CF* APIs
associated with NSDictionary. As such, there are likely method
invocations one might make on NS* that will require multiple calls to
various CF* API. And as someone else [can't find the excellent
message] pointed out, the hashing behavior of NSDictionary is rather
generalized and, therefore, likely inefficient in certain situations.
In such situations, the underlying CF* APIs might be exercised to
instantiate a much more efficient dictionary that could be used via the
NS* APIs.
Unless the developer has actually done the instrumentation work
necessary to determine that-- in fact-- hashing issues are a
performance bottleneck, the application has been architected such that
all unnecessary hashing events have been eliminated, and exactly how
the hashing behavior is causing slowdowns, attempting to optimize
through the use of CF* versus NS* APIs will be a complete waste of time.
---
Maybe this is just one of the cases where java is faster (Java is very
much geared towards database and server side stuff, while cocoa is
geared towards gui, so I wouldn't be surprised if this was the case. I
haven't heard any comparsions with the CF* objects themselves, so
maybe they are faster.)
Java is faster because Java is a statically bound language and, as a
result, the VM/JIT can optimize the heck out of method dispatch.
Objective-C's dynamic binding allows for extremely elegant solutions,
but it comes with a price at the individual method dispatch level
simply because ObjC must look up the method to be invoked upon every
method invocation -- the JVM can infer what specific method
implementation is to be invoked directly.
When comparing the performance of Java and Obj-C, doing so at the raw
"# of invocations/seconds" or "speed of object insert/removal in
dictionary" is not really a fair test. Instead, the performance
comparison must be pushed up to a higher level. While the JVM may be
able to dispatch more method invocations per second than ObjC, it
typically requires many more lines of code to build an app in Java vs.
ObJC and, as such, those extra lines of code on the Java....
The fastest and most bug-free line of code in any application is the
line of code that never had to be written in the first place!
As a result and when adding in the issues of developer productivity,
cost of change, cost of ownership, and other issues, it is most often
the case that the absolute fastest language/VM/runtime is not
necessarily the fastest overall solution.
b.bum
_______________________________________________
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.