• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java performance fallacies  RSS feed

 
meenakshi sundar
Ranch Hand
Posts: 152
1
Java Python Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Authors,


Interesting title that you have brought out ,and congratulations for that ?

Java performance has always been a contentious topic all along ,What in your opinion are the major fallacies of java performance?

Thanks
Sundar
 
Campbell Ritchie
Marshal
Posts: 55761
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
meenakshi sundar wrote:. . . Java performance has always been a contentious topic all along . . .
Has it? I know the earlier versions of Java® moved with all the verve and élan of a snail with bad arthritis, but those days are long past and whenever I try Java® code against another language, I find the Java® is just as fast. Maybe that is the first fallacy.

Have a look at the classic interview with Brain Goetz about performance; his recommendation for fast code is quite counter‑intuitive. He mentions a few other fallacies in that link.
 
Charlie Hunt
author
Greenhorn
Posts: 11
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good suggestion by Campbell Ritchie. The interview with Brian Goetz is a very good read with good suggestions.

Some of the performance fallacies that come to mind for me include:
1.)  Object allocation is expensive. Unless it is a really large object allocation, say a really large array, object allocation in HotSpot is really cheap, around 10 CPU instructions on most hardware platforms. The consequence of high object allocation rates coupled with object lifetimes that span beyond a rather short time, where "short time" is defined as long enough to survive enough young GCs to be promoted into old generation. This is especially true for Parallel GC and Serial GC, and to a certain extent CMS GC, but not as much of an issue for G1 GC.
2.)   A program written in C or C++ will always perform faster than one written in Java.  If you have your doubts, here is an experiment for you try. Write this program in both C++ and in Java. Create an abstract class called Shape which has one virtual method called area() that computes the area of a some shape. Then implement three classes inheriting from that Shape abstract class, one for a Square, Rectangle and a Triangle. Then you need to create a bit of code call only one of these implementations of the Shape.area() method some large number of times so as to track how long it takes to do that computation. In Java you have to be careful in how you do this because a modern JVM's JIT compiler can dynamically optimize what it sees as dead code to being eliminated. So there are some tricks to employ here like making sure methods return a value, and there be an operation done on that value. Compile the C++ version and compile the Java version, go run them and see what they report for throughput on those computations. For bonus points, update the programs to call two implementations of Shape.area(), re-run things, and then update the program to run all 3 implementations. If you observe slow downs when running the Java implementations, what you are seeing at the one implementation and two being called is de-virtualization. The JVM's JIT compiler can dynamically optimized based on code paths taken by the application and the classes it has loaded. So by exploiting capabilities of a dynamic compiler in the JVM, one can write Java programs that can outperform C/C++.

There was a JavaOne 2010 session a couple years ago by Tony Printezis and John Coomes that touched on some things in this area.  I couldn't find a link to the presentation. But here is a link to JavaWorld article by Dustin Marx about its content: http://www.javaworld.com/article/2073581/javaone-2010--the-garbage-collection-mythbusters.html
 
meenakshi sundar
Ranch Hand
Posts: 152
1
Java Python Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That was a very good read of Brian Goetz interview ,thanks for suggesting that.

Agreed, with the advent of modern JVM's JIT ,all those age old inherent performance hinderants were eliminated and it is now thing of past ,java is as fast as any other modern language.

Still with that being the case,would it be fair to say with Bad design /Bad code affects the performance in a big way,How can we avoid that?

Thanks
Sundar

 
Charlie Hunt
author
Greenhorn
Posts: 11
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
meenakshi sundar wrote:That was a very good read of Brian Goetz interview ,thanks for suggesting that.

Agreed, with the advent of modern JVM's JIT ,all those age old inherent performance hinderants were eliminated and it is now thing of past ,java is as fast as any other modern language.

Still with that being the case,would it be fair to say with Bad design /Bad code affects the performance in a big way,How can we avoid that?

Thanks
Sundar


Avoiding bad design / bad code ... reviews should help.  Hiring people with good skills.
* Note: I am not a fan of interview coding. There are many (better) questions that can be asked that can articulate whether a person can put together a good design and write good code. I often say, I can teach any moron to write a program. It is a totally different story to teach them how to do software engineering (including good programming skills).
 
meenakshi sundar
Ranch Hand
Posts: 152
1
Java Python Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good points ,and Code/Design smell tools should help to some extent.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!