|
|
|
|
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.
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.
Java performance tuning related news.
Back to newsletter 058 contents
