|
|
|
|
Back to newsletter 088 contents
I was using a C# client (not a client I wrote, it connected to a Java server). Its performance sucked. Of course, as I'm not one of those slashdot ranters, I know better than to say it was C#'s fault. It was, of course, that the particular configuration that I was running had not been performance tuned (or even performance tested) - the same is true for anything written in any language. You can get sucky performance from anything - and even well written code can produce bad performance, so I don't even assume that the code was badly written. Any non-trivial app really needs performance testing, and quite probably performance tuning too.
Then the C# client deadlocked. At least I think it deadlocked - it stopped updating the app screen, which went white-ish, and showed the hourglass cursor. It was taking no CPU (from previously maxxing the CPU), and would not refresh at all. It had 40 threads running - or, more precisely, sitting completely idle. My experience is that this very likely indicates a deadlock.
So, naturally, I asked the dev team behind the client (it was a production client, developed in-house by one of my customers), how to dump the threads so that I could send them the listing of the deadlock. Apparently you can't. Well, you can, but you have to attach something - a debugger I think. Something that I didn't have. You can attach remotely, but that was problematic given where I was and where they were. There isn't any simple mechanism to just get the dump. Coming from the Java world, where we've had cntrl-brk (on windows, and on unix cntrl-\ or kill -3) from practically the very start, this felt like stone age technology. Is C# really that backward, or was it just lack of experience on the part of the dev team? I don't know, I don't do any C# development. I was left distinctly unimpressed with C#. But I'm all for competition. So if Microsoft engineering is reading, I have a suggestion - go and read the Java troubleshooting guide, and make sure a production C# app can do the same types of monitoring or better. It's the difference between a runtime system that is prime time, and one that is not quite ready.
Now on with the newsletter. We have our usual lists of Java performance tools, news, articles, and we also have Kirk interviewing Dan Diephouse on XML performance; Javva The Hutt tells us about the effects of the credit crunch; and, as usual, we have extracted tips from all of this month's articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 088 contents
