Weiqi, I agree with you. And C is faster than C++, and assembly language is faster than C.

Well, as a programmer, I can reason both sides of the argument. I can see the points both Anonymous and Joseph made.

But then there is reality. As a user, Java programs have that unmistakable feel of slowness associated with them. The kind of slowness that prompts you to tell the person watching it with you, "I'm sorry. This program is kind of slow. It's written in Java."

I don't know how to square the reality (or my perception of it) with the theory. It's one of those "in theory theory is the same as practice, but in practice theory is not the same as practice" monents.

So why don't we settle everything with a Google Fight. :)

Sadly, what I think weiqi is getting around to saying is that "perceived" perception is in the end, the deciding factor. I almost agree with that. I too have seen that Java is faster than C/C++ in many areas, and especially on the server side where it reigns supreme, we all know that the JIT kicks in after a little while which is most often seen on the server side. Even so, the Java client side desktop world is making a come back. There are a few reasons why.

First, as someone told me the other day and it made good sense, web/html is kind of out. When it came in strong, computers were too slow and desktop interaction was limited. HTML fit the bill because you could deploy quickly, and limited user interaction was all that was needed. To be honest, a lot of apps are still better written as web apps than client side applications.

That said, the sophistication of todays applications are much more difficult to develop on the web. While MS hasn't had an update in years and Mozilla/firefox is coming on strong, a few years back there were so many browser issues it made it difficult to develop solid thick-client like apps without a lot of extra code to handle all the versions and nuances. Today its a bit better, and Flash and other tools make it more capable to support. Even so, a site that has to handle 1000s of users means a LOT of hardware is needed. By moving the user interactive GUI rich application to the client with a decent instaler that allows installation via the web as well as updates, and putting the bulk of the functionality there, you offload the performance needs of server-side only applications to the client. Sure, they have to log in, wait for DB transfers, but the majority of the functionality can be done in the thick client.

This all comes about to perceived perception. It is a well known fact that users are impatient, often after 5 seconds or less of no activity. If you work in an IDE written in Java and scroll a large source file and it lags, most anyone would think "Man, this sucks..its written in Java? Java must suck, its slow STILL!". Sad truth is, a lot of people don't consider the design of the app, how its written, etc. It could very well be a bad 3rd party library that is killing the entire app. It could be a very badly written app. But like someone else said (I think Tim), Java is almost never the culprit. If people would STOP blaming Java itself and look around at some very robust Java built applications, they might think again and realize it very well could be the app they are using is badly written. I have worked with projects that are badly written, they DO slow down significantly. I've also worked with smooth well written products and they are just as bit as fast (to the eye) as any other app I have used.

Another myth, Java has no pointers so memory leaks dont occur is a BIG LIE! In fact, it is VERY easy to cause a memory leak in Java. While some think setting a variable to null is ugly code, shouldn't have to be done, etc, infact they are wrong in most cases. Just gotta learn when to do it. Method scope variables dont need it, but class instance variables are a culprit that hang on to object references even when not needed. Anyway, don't say Java is slow cause hello world runs fast, etc. Like Joseph said, Java DOES have a runtime loading issue that is being partially resolved in Java 5.0 using a shared library or something that will keep parts of the library easily loaded so the startup should be faster. I have heard JDK 1.5 is showing 20 to 30% performance gains on Swing apps with no change in hardware, just a recompile (or maybe even just redeploying).

Like other said, do some testing. Also, testing has to be done in a number of ways. You can't write a couple simple small apps and that shows it all. Test in different areas, and in different ways. Also, test small and large data sets. Like many have shown, Java takes a few seconds or more to really get going. And, unless you are completely stupid, it is very easy to see how a JIT at runtime that knows the hardware it's on can easily optimize and native compile chunks of code at runtime and make them faster than any c/++ compiler can do, not to mention optimize by watching/noticing slow areas and reworking that bit of code to make it faster.

I am not the one to troll on a normal occasion but uninformed people such as yourself bring this in me... Your C++ brain seems slower than Java.

The latest comments illustrate my frustration.

Kevin is rught on when he pointed out that my worries is about the end result.

The paper cited by Somebdy was what prompted me to write this rant (the third item). I did not link to it out of respect for the professors.

Anonymous II's comment about my C++ brain is purely speculative and wrong, bordering on personal attack and he/she/it knows it.

Tim suggested that I should blame the architect/designer/programmer rather than the language. I agree that most of the time performance problems are the result of a wrong design or a wrong implementation. But that should happen equally likely in both C++ and Java and can't explain why Java programs are slower than C++ programs.

I love Java and c++ user's suggestion---"If you disregard the VM-startup time." And I can add a few things to the list: object creation on the heap, all methods are virtual, object references are indirect, no inline methods, every array access has to be bounds checked, the JIT has to count every method invocation, the HotSpot engine has to take time away to do its optimization work, managed (wrapped) access to system/foreign APIs.

I'm not claiming that one cannot write performing Java applications that's adquate for its purpose. I'm just pointing out that the Java programs that I use everyday are not as fast as their C++ counterparts.

Please tell me that you are NOT a Java developer! JavaScript != Java. Other than horribly copied semantics, JavaScript has NOTHING in common with Java!

Sorry - my comment should go to Anonymous, not to Somebody again.

Forget about C++ !! Forget about Java !! The fastest is the old plain Assembler !!! I can do things 20 times faster than anything else using the old and good Assembler. Who cares about portability ? Every body uses just intel and windows! And Assembler beats all !!

Could somebody explain the following fact: I made 2 "Hello world!" programs. One in java and the other in C++.

Java took 10 secs!
C++ took 40 secs!

Java:

class HelloWorld
{
public static void main (String [] args)
{
for(int woei = 0; woei < 200000; woei++)
{
System.out.print("Hello world!");
}
}
}

C++:

#include <iostream>
using namespace std;

int main() {
for(int woei = 1; woei < 200000; woei++)
{
cout << "Hello world!";
}
return 0;
}

One thing I can say about your computer is that your computer... well... ain't good. Maybe you mistyped and wanted Milliseconds/NanoSeconds instead?

Why is C++ slower than Java? http://razi2.blogspot.com/2008/04/why-is-c-slower-than-java.html

std::cout has to share buffers with C stdio, so its default buffering really sux, it may be sending the output in every iteration which is horribly slow to disable the shared buffering, write this line of code before any use of std::cout std::ios_base::sync_with_stdio(false); this will speed up std::cout dramatically, but you can no longer use stdio

Can we categorize the question further more?..
a) Java Faster Than C++? -- with respect to small applications/code.
b) Java Faster Than C++? -- with respect to medium applications/code.
c) Java Faster Than C++? -- with respect to large applications/code.
So can i know the answer for the above?

asm (fastest) c/c++ (fast) java (medium) javascript (slow) FuckJava (HELL SLOWEST) XD