• Post Reply Bookmark Topic Watch Topic
  • New Topic

The Java Performance Companion Question: top 5 things to watch out for  RSS feed

 
Salil Wadnerkar
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For a beginner who does not know the intricacies of JVM, what are the top 5 things to watch out for regarding performance?
 
Charlie Hunt
author
Greenhorn
Posts: 11
5
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Salil, this a very good question, and it is one I hear occasionally, along with one that likely has a lot of different responses or opinions. I think best answer I can give is first write your Java code in its most natural form. Then, if its performance is not meeting expectations, then tune the JVM. If it performance is still not meeting expectations, then profile the application to find the problematic areas. Refactor those areas, (maybe in the worse case you have to maybe re-design something), check the performance with the changes. Then continue to iterate until you have met the performance objectives.

To help mitigate risk, as you go through the earlier phases of software construction, prior to implementation, you could do some risk mitigation by look at potential areas of performance concerns to create smaller prototypes of those area, (not suggesting micro-benchmarks), something large enough to be able to mitigate performance risks. This would help identify performance issues a little earlier.

Here are some general practices that I think also tend to fit into good programming principles too.
- Small methods are very easily optimized by HotSpot's JIT compiler, especially if there is are very few or a small number of branch conditions. IMO, the most powerful performance optimization in HotSpot's JIT compiler is inlining.  The bigger the method, the more branch conditions, the more challenging it may be for the JIT compiler to optimize, (not always the case, but a generalization).
- Don't be afraid of immutable objects. Object allocation is very cheap in HotSpot, approximately 10 CPU instructions for most platforms, unless it is a really large array which gets handled differently. The consequence of high object allocation is not necessarily GC time, (as in how long the GC takes), the bigger impact is how frequently those GCs occur. And the frequency of GC is what influences how rapidly, and how many objects get promoted to old generation, where collection of those objects tends to be more expensive, or the consequences of them being in old generation are a little difficult, especially with the Serial collector, Parallel collector and to a certain extent CMS GC. G1 can avoid some of the consequences of objects getting promoted to old generation that are present in CMS such as old generation fragmentation.

There are likely others on this forum who have additional suggestions. I think lots of have opinions on this subject based on past experience.

Hope that helps.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!