[cajun]

Hi. I'm just curious, has anyone done any benchmark testing of algorithms in ObjC vs C++ vs Java? C++ performs linking, method selection, etc at link time, whereas Java & ObjC perform everything at runtime, so will the latter 2 take a large speed hit? And what about ObjC vs Java? Will ObjC become even slower than Java if a programmer uses id for everything (instead of static typing)?

[ali]

Well, it all depends heavily on what the algorithms and the usage patterns in a given piece of code are... Some general answers:

Overall, like C++, ObjC is basically C, compiled down to machine language, so it will be fast. Once a message has been sent once, ObjC message dispatching is almost as fast as (within a few cycles of) direct function calls. Java also has just-in-time compilation which optimizes the byte codes on the fly down the basically machine language, and once Java apps get going they can be quite fast.


One big difference between ObjC/C/C++ and Java is that the latter does a lot of work at runtime (such as on the fly compilation and managing the class information), and ends up allocating a lot of memory to handle all this. A Java app might end up easily needing 10-20 times the memory of an equivalent C++ or ObjC app, and it's not uncommon for Java apps to use 20-40M of memory. This means computers that are short on memory will page a great deal more while running Java apps, and this will slow the system down.


Ali

[lindberg]

Will ObjC become even slower than Java if a programmer uses id for everything (instead of static typing)?

The way you type your variables makes absolutely no different at runtime. At runtime, the message will be sent to whichever class the object actually is, regardless of the way it was typed in the code.

Binding and typing are two different things -- Objective-C always uses dynamic binding (determining which method to execute at runtime), whereas Java usually does but with final, private, and static methods will use static binding (where the compiler determines the function and inlines the call to it directly).

Typing, on the other hand, is just for the compiler's benefit. If you statically type an object, you're telling the ObjC compiler which class to treat it as, and the compiler can then give you much more accurate warnings when your has sends messages to it that aren't declared and the like. With "id", as long as the compiler finds a method declared in some class somewhere that matches what's in your code, it won't complain, leaving you to discover the mistake at runtime with a doesNotRecognizeSelector exception. In short, it's always better to type your variables instead of using id, unless of course the variable could actually be a reference to more than one class, in which case it's more convenient since you don't have to do a lot of extra casting.

Since the Java compiler sometimes does use static binding, it has to be 100% sure of which class the variable will be at runtime (otherwise it could inline a call to a method on the wrong class, very bad). Therefore, all casts are actually enforced at runtime, and any unknown method calls are errors. With ObjC, these are warnings (the method might actually exist at runtime even though it's not declared -- the programmer might know better than the compiler). This is why ObjC warnings should not be ignored -- they're often as bad as Java errors.

[Whisper]

With Java, it'll always be slow. With ObjC, the "slowness" depends on how much you use messaging vs functions. If you write a straight C program that happens to be compiled on an ObjC compiler, it should run just a fast as it would have if you'd used a normal C compiler. But if you do everything with messages, your code would be about as slow as Smalltalk. I have no idea where C++ fits into this.

[ali]

Originally posted by Whisper:
<STRONG>With ObjC, the "slowness" depends on how much you use messaging vs functions. If you write a straight C program that happens to be compiled on an ObjC compiler, it should run just a fast as it would have if you'd used a normal C compiler. But if you do everything with messages, your code would be about as slow as Smalltalk.</STRONG>

I don't know how slow or fast Smalltalk is; but in ObjC, once a method has been sent once, subsequent invocations of the same method are very fast --- just a few more instructions slower than a function call. It's very rare in apps that you will see the message dispatching function as a performance issue.

Ali

[cajun]

Hmm... Why are subsequent invocations of methods very fast? Is it because the ObjC runtime caches the selectors?

[lindberg]

Hmm... Why are subsequent invocations of methods very fast? Is it because the ObjC runtime caches the selectors?

Yes, the class objects keeps a cache of the selectors, and which method implementation (function address) each one mapped to.

[davechen]

Does Objective C do garbage collection? That might make Java slow down occasionally.


Also Java is slow to launch because the virtual machine has be loaded and set up.

[Wixar]

www.acm.org/pubs/articles/journals/cacm/1999-42-10/p109-prechelt/p109-prechelt.pdf
is a study of the relative efficiency of programs written in C or C++ and Java by graduate students given the same task (find the words that telephone numbers can make). In a nutshell, here's what they found:

The Java implementations took two to three times as much memory as the C or C++ ones, on average. Even the best Java implementations took more memory than the average C or C++ ones.

The median processing time of the Java implementations was more than three times that of the C or C++ ones. The fastest C or C++ implementations were ten times faster than the fastest Java ones.

Programs written in C were "substantially faster" than those written in C++.

There were no major differences between the code lengths of the C or C++ and Java implementations, or the time spent writing the code.

So it looks like Java takes just as long to write and makes your code less efficient for the problem at hand.

(Of course, the greatest differences were between the different implementations, not the languages. How you write is much more important than what you write in.)

-Peter

[aleph_null]

I couldn't read the article. It wanted a password(?).

But I'd argue that the overall efficiency of one language vs another is really related to the problem at hand. Starting from scratch on a strictly computational task like the one you mentioned is quite different from starting from scratch on a GUI-based application which has to deal with model/view issues, drawing primitives and view hierarchies, user input, persistence of data, yadda yadda yadda. The language and the standard libraries it tends to include will hugely affect programming time in the latter case.

Hello, World written to a console output is probably easier and faster to write in C than in Java, and it certainly would be a smaller amount of object code and run-time overhead. But it doesn't do much. Hello World written from scratch into a view in some windowing system will almost always be easier to write in Java. And the Java one will be highly portable. And, as soon as you have to allocate and de-allocate memory by hand in the C version, you're going to have bugs to fix and leaks to plug.

On the other hand, I agree with your emphasized statement. Good tools don't make a good carpenter.

[e-martin]

Originally posted by Wixar:

&lt;snip&gt;

...is a study of the relative efficiency of programs written in C or C++ and Java by graduate students given the same task (find the words that telephone numbers can make). In a nutshell, here's what they found:

The Java implementations took two to three times as much memory as the C or C++ ones, on average. Even the best Java implementations took more memory than the average C or C++ ones.

The median processing time of the Java implementations was more than three times that of the C or C++ ones. The fastest C or C++ implementations were ten times faster than the fastest Java ones.

Programs written in C were "substantially faster" than those written in C++.

There were no major differences between the code lengths of the C or C++ and Java implementations, or the time spent writing the code.

So it looks like Java takes just as long to write and makes your code less efficient for the problem at hand.

(Of course, the greatest differences were between the different implementations, not the languages. How you write is much more important than what you write in.)

-Peter[/QB]

Interesting study! Just a couple of thoughts:

- It seems like the kind of problem where C is perfectly suited (a sequential combinatoric search, probably with some hash table lookups in a word dictionary), and where little can be gained from OO design and programming (which was also the original question).

- OTOH, it's a write-once, run-once program to generate some static information, so the best suited language will (nearly) always be the one the developer knows best (no learning curve). I guess a good perl hacker could do a fine job - and these people (often being sysadmins) have CPU cycles to boot.

- I, for one, would have written this program in Java for all the wrong reasons: It just happens to be the language I know best and it's installed on the PC on my desktop (so I wouldn't have to leave my desk to do it) and on my new MacOSX toy (which would make it a fun job).

It would be interesting to see a similar analysis for GUI-heavy apps and some networking stuff, e.g. client-server with complex data exchanged. If it still takes the same time to write the apps in all three languages, then I must say that 10 years of on-and-off OOP have been to no avail...

Ciao

[clarkgoble]

It seems to me that the trick of using C++ (which I love) is deciding *when* to use the various C++ features. Often one can create a method and some private methods which are basically just C. I don't know the timing issues, but I'd suspect that in those cases the memory/speed costs aren't that significant.

Where people go wrong is in overusing things like Templates, Exceptions and so forth. Obviously good design does the design before the coding, and class/template libraries can be a boone. However there is an old adage "of just enough and not too much" that I think fits in with C++.

Sometimes I think programmers end up serving the language rather than vice versa.

[Whisper]

Originally posted by clarkgoble:
<STRONG>Where people go wrong is in overusing things like Templates, Exceptions and so forth.</STRONG>

One could argue that a properly designed language & compiler wouldn't care about how often you use such features. Of course, one might be wrong.

I don't know which it is yet

[clarkgoble]

Well in the real world one cares less about whether something is "properly designed" than whether it does the job well. (-:

In my opinion C++ does everything I need, has most of the object aspects I want, and has the others for the occasional times when I need them. My personal opinion is that people are taught all sorts of weird rules that don't always make sense.

Here are a few off my favorite "rules" that I frequently break.

"Anything with more than 5 lines of code ought to be in it's own function" - that doesn't always make code more readible or understandable. Sometimes it is better to be able to see at a glance what is going on.

"Don't use gotos" - often a goto can simplify dealing with error conditions and in a way much cleaner than using exceptions. (And without their overhead)

I've not tried Obj-C yet, so I don't know how much all this applies. Certainly one big flaw in C++ is the lack of good dynamic messaging. However that really isn't that big a deal for many types of applications. I agree though that C++ is growing bloated. It is starting to remind me of Ada in some ways - a language designed by a committee that wants it to do everything.

The problem with Obj-C though is that it really isn't "everywhere" with lots of class libraries, development systems and so forth. Likewise C++ doesn't have the overhead of Java and avoids the hits of automatic garbage collection and the limits on pointer-like operations that Java has.

[ 06-19-2001: Message edited by: clarkgoble ]