Why Java is slower?

[Niranjan Prasad]

I heard that Java is slower than the C.

In C:
After compiling we get the .obs file
This .obs file is excuted and by what?Is it Compiler or anything else?
After, we get .exe and this is executed by the o/s.
What I mean to ask is who produces the .exe?

In Jav:
After compiling we get the .class file
This .class file is excuted by JVM.
JVM produces the get .exe and this is executed by the o/s.

Java is doing the same steps as C and why Java is slow

[Layne Lund]

No, the steps are not the same. In C, the program is typically compiled to an executable binary (a .exe file in Windows). This .exe file can be executed directly by the operating system. (Note that the .obj files play a different role and shouldn't even be discussed in this particular context.) In Java, the program is compiled to .class files. These files are not typically recognized by the operating system. The user usually needs to install a JVM that translates the .class file into something the operating system and computer can understand. This translation happens EVERY time you run a Java program. Compare this to a C program where the translation occurs only once when you compile it. Also note that in Java, the JVM does NOT produce a .exe file. In fact, this is a Good Thing because .exe files are specific to Windows. There are other types of executable files for other operating systems, such as MacOS and Unix.

If you want to understand this better, google for "machine code" and "binary executable". That might bring up something that will help you make sense of this.

Layne

[ October 23, 2005: Message edited by: Layne Lund ]
[ October 23, 2005: Message edited by: Layne Lund ]

[Ernest Friedman-Hill]

It would also help for me to point out that, in most cases, as has been shown many times by benchmarking, Java is not slower, and, depending on the application, on the JVM, and on the C/C++ compiler used, Java can be [i[faster[/i] than C.

Most people (despite what everyone seems to think!) will never write an application where any difference between the performance of various languages really matters. Use the proper tool for the job -- whichever language makes the program easiest to write is generally the best one to use.

[Norm Radder]

I dont' know what Java application is faster than C. EVERY java app I have is slower than every C app I have. By seconds!!

[Barry Gaunt]

One problem is the JVM startup time, class loading and initialization time. Once all the >infrastucture< is up and running and "raw" bytecode runs, then the race should be about even.

[Ray Horn]

I ran into interesting thread in Performance section on this:

performance thread

The article link in first post makes interesting points. Although not at beginner level.
[ October 23, 2005: Message edited by: Ray Horn ]

[marc weber]

Originally posted by Barry Gaunt:
One problem is the JVM startup time, class loading and initialization time. Once all the >infrastucture< is up and running and "raw" bytecode runs, then the race should be about even.

That's my impression. Once it's up and running, I've never noticed Java to be the least bit slow.

[Layne Lund]

Originally posted by Norm Radder:
I dont' know what Java application is faster than C. EVERY java app I have is slower than every C app I have. By seconds!!

The question is, do you have two versions of every program, one in Java and one in C? It doesn't make sense to compare two programs that do completely different things.

Layne

[Norm Radder]

No I don't have 2 versions. I've only written one it both C and Java.
Its a very empirical thing, all C programs I use seem to start and be faster than any Java program. Most of it is in the startup.
I've written something of an application server that will execute other java programs and with it the other programs do load much faster.

[Layne Lund]

Originally posted by Norm Radder:
No I don't have 2 versions. I've only written one it both C and Java.
Its a very empirical thing, all C programs I use seem to start and be faster than any Java program. Most of it is in the startup.
I've written something of an application server that will execute other java programs and with it the other programs do load much faster.

Like I said, this isn't very good empirical evidence unless you compare two versions of the same program. For example, comparing a bubble sort in Java to a quick sort in C++ is pointless because bubble sort is slow no matter what language you use to implement it. Similarly, comparing "Hello, World" in one language to a enterprise database application in another is not fair. I know I'm giving an extreme example here, but the concept still applies.

Layne

[Niranjan Prasad]

hi
This is Niranjan,who posted the question.

In my i have find that compiling and execution is done by Compiler itself.

As we know the basic, that Compiler executes taking the complete code or program from harddisk to RAM at once and executes

Whereas the interpreter takes each line of code from hardisk(.class) and to RAM executes,that's y slow.

What u people say?
Another thing i want to confirm that execution of code is done by compiler in C lang.

[fred rosenberger]

The compiler does not EXECUTE the code. think of the compiler as a translator. it converts the language of C into a language the Operating System can understand. once the compiler does it's magic, the OS can run the .exe directly. the .c file is only compiled once, and the compiler is never needed again (until you change the code).

In java, when you run the javac command, you are again translating the Java-language file into a language called "bytecode". the OS does not understand this language at all. There is another program, the Java Virtual Machine that DOES understand the bytecode. the JVM's job is to convert the bytecode into a language the OS understands. the JVM converts the bytecode EACH TIME the program is run.

[marc weber]

Here are a few references that might be of interest (in reverse chronological order)...

...Java has really made great gains in overall performance that can in fact put it on par with C++, if not a little quicker! There are various benchmarks that have reported Java algorithms running quicker than C++ equivalents... You will of course find many benchmarks finding the converse. What this shows is that they're at least comparable which is enough for me to imply that Java is fast, and I'll leave it to the benchmark zealots to fight over their nanoseconds.

I think Java is somehow still seen as an interpreted language; in fact, it does get compiled to native code using Just In Time (JIT) compilation. It is also a myth to think that JIT code is slower than pre-compiled code...

Ref: http://www.osnews.com/story.php?news_id=10729 (Andy Roberts, June 2005)

... The next myth is that Java is slow. Obviously, since it is an interpreted platform, it can't be anywhere as fast as native code. For some reason, these folks have never heard of Just In Time (JIT) compilers. I can understand that. This is an industry that prides itself on instruction counting, so relying on a JIT compiler may seem like voodoo. The fact is that JIT compilers now produce code that is just as fast as native compilers. And, in some cases the code is faster. JIT compilers can analyze runtime patterns and adjust compilations. Native compilers can't do that.

Ref: http://weblogs.java.net/blog/yensid/archive/2005/02/java_game_devel.html (Doug Twilleager, February 2005)

We can skip over the myth that Java execution is slow because it is interpreted. It's simply not true. JIT (just in time) and AOT (ahead of time) compilers are the norm for embedded Java.

Ref: http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=8112 (William Wong, June 2004)

Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks...

Ref: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html (J.P. Lewis and Ulrich Neumann, Computer Graphics and Immersive Technology Lab, University of Southern California; January 2003)

Myth #1: Java has to be slow.

Myth #2: Java is interpreted.

... Previously, a Java Virtual Machine was primarily an emulator. Soon, however, some JVMs began compiling the Java code to native code as a part of the startup process. However, modern virtual machines do something which C/C++ usually does not: dynamic compilation and optimization. HotSpot, Sun's current JVM, does some pre-compilation, but also profiles your code at runtime. This allows it to figure out the most important areas to optimize, and then to make the optimizations as your program runs. In addition, HotSpot includes a new garbage collector without the annoying tendency of its ancestors to bring your application to a halt.

Ref: http://www.identicalsoftware.com/ogs/2000/java.html (Kenn Flynn, Naval Research Laboratory; 2000?)

The myth of Java's poor performance originates from these three misconceptions:

that Java is interpreted and therefore slow,

that Java's safety features in the area of typing and memory management introduce large amounts of overhead, and

that system performance is primarily a function of CPU opcode selection.

...not only are none of them true, an understanding of modern hardware architecture and a survey of typical systems shows that Java is arguably a superior choice for high-performance applications; for instance, in a 24x7 n-tier application, Java's defragmented and compacted heap is likely to be both more robust and higher performance than a memory management scheme cooked up by the average C++ programmer.

Ref: http://www.sdc-us.com/research/measuring_java_performance.htm (Larry O'Brien, System Dynamix Corporation; 1999)
[ October 26, 2005: Message edited by: marc weber ]

[Mr. C Lamont Gilbert]

Fundamentally the OP is correct. Some folks have a hard time accepting that a Java program is actually a C program.

In C, the compiler creates the obj files. The linker will link them into an executable. The OS will run the executable.


In Java, first there is created a JVM which is a C/C++ program. Then there are class files given to this C program to tell it how to behave. The JVM does a further compile on the class files to make them more friendly to running on the OS. (more C like)

Function for function a native C program can not be faster than a native Java program because they both C programs. However, overall a C program can be faster when the java program brings along more than you require.


C will destroy Java in a simple Hello World program. But create a large complicated program and the victor goes to the person who writes the better code. The only thing is in Java this is guaranteed to be at least two seperate entities; One the JVM writer, the other the java writer.

[Steve Morrow]

Some folks have a hard time accepting that a Java program is actually a C program.

Count me among that group. There's no requirement that a JVM (HotSpot or otherwise) be implemented in C, or that HotSpot compilation results in something "more C-like" (both get compiled to native code).