Azureus is Slow Because of Java?
October 26th, 2006I came across a post on Java Lobby while browsing Digg.com. It explains that Azureus, a popular BitTorrent client, has shown that Java is a major liability with sluggishness being a primary concern. The suggestion reminded me of my own performance problems with Azureus but also LimeWire, a Gnutella client which is also written in Java. I remember times when I attempted to run searches with LimeWire and it would not only run slowly, it would cause the whole computer to become unresponsive. And that was on my snow iBook, a Mac. So the performance issue goes beyond Windows.
You could dismiss the performance problems with these software packages in the early stages of the projects but it comes to a point where attention and effort is put into tuning performance. Given that these clients have been around for a considerable amount of time it must be something which cannot be tuned at this level.
What appears to be the issue is high network traffic. And the nature of these file sharing clients could specifically be the problem. They both generate frequent connections with many remote peers. Opening and closing sockets frequently has been a costly activity for any piece of software and in this case it seems more acute.
If it truly is a Java problem with high network traffic, why have they not dropped in a native solution to handle the connections? With other interpreted languages it is common to link into a natively compiled library for the sake of performance. For example, when Perl needs to do any major cryptography or graphics rendering it simply links into an established and very capable C library. The very same should be done here.
In fact, libtorrent is available on more platforms than Sun supported Java releases. Why not simply link into that very capable library which is written in C++? It seems that linking Java to C++ is not a simple undertaking and something most Java developers would dread. And that is reasonable. Such work falls outside the normal Java developers daily routine and new and unfamiliar concerns are introduced when linking to native libraries, such as memory protection and type safety. It is unsafe territory.
So what can be done? Fortunately Java is becoming open source, slowly but surely. The dinosaurs who kept Java under wraps for too long have now lost their exclusive control over the platform as mounting pressure forced Sun to open it up. And with Java 6, code-named Mustang, we will see an open Java platform. Eventually this dusty corner will be eliminated from the Java runtime.
But in the meantime, try µTorrent for Windows. It is written in C++ and runs extremely well. And at only 170kB, it compares well to Azureus which comes in at over 8mb.
October 28th, 2006 at 8:39 pm
You know, I could see a network issue being the problem, if only J2EE servers were slow too, but that's clearly not the case as they dominate the server development/deployment arena by far. Java, slow, far from it. There are some things that it may not be as fast as native, but I've worked on several large scale Swing applications for internal company use that were plenty fast with large queries, fast UI responsiveness and more, and not only did we get the apps done faster because of Java's noticeably easier language than C/C++, but it ran on our internals mac/linux/windows/solaris desktops with no porting requirements. Trying to build a native app that runs both smoothly AND on different platforms is much more difficult with native, such as C/C++. Now, I am not taking you for a fool and suggesting you don't know this, but I am, once again, defending Java from someone who is speculating at why something runs slow with the only plausible reason being Java. It is just so easy to blame the underlying language on why it's slow, and not hardware, the OS it is running on, or perhaps the code itself. Azureus is kewl software, I use it. Never had a problem downloading or uploading many files at once. So by what your saying, then I should be saying that this Java app is as fast as or faster than native apps because I do not see any slugishness.
Sure would be nice if people would stop with the FUD regarding how slow Java is.
October 29th, 2006 at 1:52 pm
I do not believe it is simply FUD you should dismiss if the source which raised the issue is Java Lobby. And as I explained, normally Java is fine. But when handling many network connections in a BitTorrent or Gnutella scenario, it appears to have a performance issue. My guess is that the creation of these temporary objects causes the short term generational memory to fill up so that it slows down the whole application. Perhaps that could be improved by pooling the objects used here, if that can be done for sockets like it is often done for database connections. That is doubtful because each remote address is unique so a native socket has to be created which is what is the costly part.
I have also considered another issue with Java applications that perpetuates the performance concern is that developers tend to use Swing improperly. It is a single threaded GUI and without proper use of secondary threads to carry out background tasks it can cause the GUI to become sluggish. And too many threads can chew up the processor and slow down the entire system. Also, locking code blocks for thread protection also causes thrashing on the processor which damages performance. When this sort of performance degredation happens often enough, I believe it shows a weakness somewhere in the platform perhaps in documentation, language features or profiling tools to get into the problem and resolve it. If that is not the case maybe the Azureus team has not considered this to be an issue. The right people looking at the problem should be able to fix it.
November 18th, 2006 at 4:38 am
I have same problems with Azureus. Seems that Java is bad choice for building bigger desktop applications, because of its poor performance. Azureus has great functions, but causes terrible slowdown. Moving to uTorrent again.