Comments on: Looks like Apple should “switch”

By: Robert Chin

Robert Chin — Fri, 27 May 2011 01:18:00 +0000

In case anyone is wondering why the performance benchmark shows such a large difference (aside from the possibility of the compare being optimized out as stated by alastair) — the Objective-C method that is being used is compare:, which is a fully unicode aware function that compares based on the ordering of fully composed unicode characters. It is likely that this method also takes into account the user’s locale in order to ascertain the ordering (although I’m unsure about this last part). But the string does need to be re-composed in order for the search to work correctly. Java’s compareTo: is not specifically unicode aware, and the documentation states that it the unicode character value (which is not necessarily “correct” when dealing with decomposed strings). To make a fair comparison, the java code should probably use java.text.Collator.

By: Random Dude.

Random Dude. — Wed, 18 May 2011 11:35:00 +0000

In objective-C, if you make the same method call over and over again, doesn’t it store it in a cache.
Forgive me if this is a dumb question

By: alastair

alastair — Thu, 27 May 2010 21:40:14 +0000

Interestingly I just fiddled with the Java code a bit and got it going faster, without the comparisons (up to 8.3×10^7 a second).

Still, as I say, I think your benchmark is of dubious validity; I'm not enough of a Java fiend to know how to stop the compiler/JIT from optimising away parts of your code that should really be being timed, and you can't really claim that Java is faster on the basis that it can optimise away the computation you were trying to time.

By: alastair

alastair — Thu, 27 May 2010 21:30:21 +0000

Unfortunately, what you're comparing here isn't the language; it's the efficiency of the string comparison routine in the relevant library; in fact, for Java I'm not even sure you're measuring *that* properly. Removing the actual comparisons from the code and replacing them with 1, 0 and -1, on a Mac Pro I get:

Java: 345065.5624568668 compare tests / second
C: inf (it's too fast for your timing method and you'd have to change the code!)
ObjC: 1644439.299682 compare tests / second

Also, I noticed that the numbers for Java really didn't change when I removed the comparisons, which makes me think that perhaps the Java compiler or JIT is optimising away the calls to the compareTo() method. You might say, well then it's faster… but of course that's only true for this synthetic benchmark, not in the real world. It's pretty clear from the numbers here that C and ObjC are faster languages, since all we're measuring here is function call/method overhead.

By: Android Dalvik VM performance is a threat to the iPhone | java rants

Android Dalvik VM performance is a threat to the iPhone | java rants — Wed, 26 May 2010 16:35:31 +0000

[...] libraries. Those are mostly Objective-C libraries and use the dynamic dispatch mechanism which I showed in 2004 was very much slower than Java. I’d really love to see the whole computer language shootout written with Objective-C [...]