Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up! 

New Relic: Try free w/ production profiling and get a free shirt! 

News September 2005

JProfiler
Get rid of your performance problems and memory leaks!

jKool for DevOps
Light up your Apps & get a cool t-shirt


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


Site24x7
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up!

New Relic
New Relic: Try free w/ production profiling and get a free shirt!


JProfiler
Get rid of your performance problems and memory leaks!

jKool for DevOps
Light up your Apps & get a cool t-shirt


Back to newsletter 058 contents

Long time readers of JavaPerformanceTuning.com know that every once in a while I take a look at C# performance articles. It's useful information for two reasons: firstly, the gross architecture is very similar to Java (as almost any virtual machine technology supporting an object-oriented language is bound to be), so sometimes this can give useful tips; and secondly, its good to see where the competition are. So far, it has always been obvious that .NET CLR performance considerations have been several generations behind the concurrent Java version. (This has generated some flack in the past, I've been told that some of the CLR engineers get pretty annoyed at my editorials on .NET performance, but I tell it how I see it).

So when I saw the link to Jeffrey Richter talking on CLR Performance and Multithreading, I decided it was time for an update. Here's what I see: reflection is being speeded up; startup time is being speeded up; the biggest speedups are from the JIT; garbage collection is being improved. No surprises - these are some of what Java has targeted for years, and still does. So, is .NET CLR now at the same stage as Java? No, not even close. Lets looks a little closer at those CLR tweaks. The startup speedup - they moved the reading of an initialization file to be asynchronous. That's a good basic tune, I've seen it many times. But by basic I mean really basic - its the sort of performance tune that everyone finds really quickly when they start looking at startup time, the really big obvious bottleneck that people feel silly that they didn't think about when they first implemented it.

A note from this newsletter's sponsor

Multi-threaded applications offer a better user experience,
generally run faster, and allow better encapsulation.
They don't have to be as tricky as you think.

And the garbage collection tweaking? They've hardcoded lots of values based on their tests "because for anybody to tweak them manually you would really have to understand the implementation of the garbage collector and what those things do". Everyone out there with production Java systems knows that what the engineers find optimal is almost never optimal in everyone else's systems, and we are grateful to have all those garbage collection parameters exposed in the JVM. Yes, it does require us to have a deeper understanding of what the garbage collector is doing, but that is the only way round, because the VM engineers cannot possibly have a deeper understand of the thousands and thousands of different applications out there. Those engineer-determined optimal values are still there of course, but as defaults in Java, not hard coded unchangeable options.

I could go on, but there's no point. Performance wise, .NET CLR is pretty obviously still at the stage equivalent to a medium 1.1 Java release, like 1.1.6, or early 1.2. And what's more, it isn't gaining at all on Java, though I think they are maintaining their distance rather than falling further behind.

As usual in the newsletter we list our usual raft of articles, performance news, items and more. One I've included is Brian Goetz's analysis of theoretical performance capabilities of Java versus C/C++. It's not all that useful as a source of performance tips, but is nevertheless absolutely fascinating. Memorize the URL, and next time you see one of those stupid "Java's not fast, nyahh nyahh nyahh" posts, dump in the URL. Several times.

In the newsletter we also have Kirk giving us another excellent roundup of performance discussions, and, naturally, we have many new performance tips extracted in concise form.

A note from this newsletter's sponsor

Proactively build better performance into your Java applications, and
rapidly diagnose and fix performance and memory issues before your
end users are affected. See Quest's JProbe in action! View the demo

News

Java performance tuning related news.

A note from this newsletter's sponsor

Wily Technology delivers what you need: Availability, Performance and Control
The most critical web applications in the world are managed by
software from Wily, the leader in enterprise application management

Tools

Articles

Jack Shirazi


Back to newsletter 058 contents


Last Updated: 2017-04-01
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news058.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us