Linked by Thom Holwerda on Sat 8th Oct 2005 18:40 UTC, submitted by anonymous
Java Programmers agonize over whether to allocate on the stack or on the heap. Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs.
Thread beginning with comment 42340
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

"Yes, Java is so fast that it can outperform C++ only in controlled lab environments. Yeah right, welcome to the real world!"

Yes. I will tell you about the real world. In the real world, Java is mostly used for server applications that do 100% duty cycle, where startup time is not important, and where the JIT can work its magic. In the real world, these types of applications are horribly unsuited to C++, and are also dangerous to write in C++. In the real world, speed of development and security are usually more important than squeezing out a slight improvement in performance, even if such an improvement is possible. C++ has neither speed of development, or security. In the real world other common options for server side application development, such as Perl, are 10 to 15 times slower than Java. PHP fairs even worse than Perl when it comes to performance.

"Not only the benchmarks speak, the real world examples speak as well. Java is at this time no performance match for any traditional compiled language."

Incorrect. For most common operations, there is virtually no speed difference these days beween that operation performed in C++ and that operation performed in Java, once the JIT has been allowed to work its magic. Again, the main problem right now is that JIT optmizations are not persistant across program executions. This is detrimental on the desktop, but of no consequence on servers. However, that will be changing as well, Persistant JIT optimizations are on Sun's to do list.

Reply Parent Score: 1

Member since:


you are changing topics. The original poster stated something about runtime performance "in the real world" and you repeated by using completely unrelated arguments about development style and security. May we take it for granted then that you don't have relevant arguments here?

As for the runtime performance you claim there is no difference between C++ and Java when all evidence shows the opposite. Take a look at which covers the topic now as well. Benchmarks end public perception conclude that Java is slow -- end of story.

Reply Parent Score: 0

Simba Member since:

"As for the runtime performance you claim there is no difference between C++ and Java when all evidence shows the opposite."

Where is this evidence? So far the only evidence you have provided is a benchmark that everyone except you agrees is hopelessly flawed.

"Benchmarks end public perception conclude that Java is slow -- end of story."

I've quoted scientific studies that say it is not. What have you quoted? A benchmark that everyone agrees is hopelessly flawed.

Reply Parent Score: 1

Simba Member since:

By the way, here are some tests I ran myself. I did not write the code, but I compiled it myself on my system. Tell me again that the benchmarks conclude Java is slow?

In the following tests, Java outperforms C on every test except for the "life" test. Tests were conducted with mingw gcc 3.4.2 on WinXP using -O2 optimization, and Java 1.5.0_04. Bigger numbers are better for all tests. Tests are averages throughout a range of sizes / numbers:

Fast Fourier Transform: C: 521.9 | Java: 528.4

Fibonacci: C: 249.6 | Java: 372.9

Life: C: 288.1 | Java: 150.8

Infilife: C: 359.1 | Java: 434.9

Again, in all tests with the exception of the Life test, Java performed better than C.

Reply Parent Score: 1