Skip to main content

Blog Bridge and performant Swing applications

Posted by robogeek on October 13, 2005 at 4:20 PM PDT

A long time ago I came to understand that human-computer-interface specialists studied what people mean when they say "the computer/application/widget/etc is 'slow'". What's meant is that the response time between the user doing something, and the widget responding to the doing, takes longer than the user expects.

"Slow", then, means unresponsive.

If the response time takes longer than a given threshold, then the user thinks the widget is "slow". If the response time is faster than the threshold, the user doesn't notice that. The slower the response time past the threshold, the slower the user thinks the application is. The threshold varies based on what request the user made. e.g. click and drag, you expect to be able to drag the object almost immediately, and the painting effects showing the dragging to be "instantaneous". What is the threshold for instantaneous? Around 50 miliseconds.

What does this have to do with blogbridge?

It has a lot to do with blogbridge. That application has been having drastically improved responsiveness over the last few months. Yesterday my computer updated itself to blogbridge v2.4 and the application now seems really fast.

Blogbridge, if you don't know about the application, is a really good RSS/newsfeed aggregator that runs on your desktop. Unlike webservice style aggregators, you have a real GUI with some nice and interesting features. As a Java app it will run on any platform having Java ... I'm running it on my Titanium 1ghz Powerbook w/ OS X 10.3.9. My system is still on Java 1.4.x since Apple hasn't yet released 1.5.x officially.

I first started with blogbridge before v1.0 (which was only a few months ago).

At the time there were many severe problems. GUI interactions were very slow, GUI repaints would often leave empty greyness, DnD operations were a pain, etc. But the UI design showed a lot of promise, and it did greatly improve my morning news-reading ritual. So I stuck it out, and now I'm glad I did.

Over that time Apple has issued a few security or bug-fix updates to Java, but as I said has not made a major JDK version number change. This means that every improvement I see in blogbridge comes from the efforts of the blogbridge team, and not due to improvements in the underlying Java.

How, then, did blogbridge turn from having mollassas-like performance to being really fast? It wasn't changes in Java, it was changes in the application. I'm not finding on their site a detailed explanation of what they did to get the UI responsiveness boost, other than some release notes statements talking of decreased memory footprint and improved speed.

This is like the transformation of netbeans from mollassas-slow to rather nice. Before v3.5 netbeans was incredibly slow, but today it's a joy to use. Again what changed was various optimizations and studying of profiling results by the netbeans developers.

This tells me something interesting -- Quite a lot of the "java is slow" may well be due to misdesigned applications. Simple optimizations by the blogbridge and netbeans teams turned a mollassas-speed applications into very nice ones.

Which then just reminds me of James Goslings blog post: Java Urban Performance Legends (and javalobby thread).

In this case James is talking purely about computation speed, and that for computation speed Java is regularly meeting C++/C computation speed. This is no doubt due to the Hotspot VM compiling bytecodes to native code, and once bytecodes are compiled it's as fast as native code. Now, while having underlying computation speed improvements are good for GUI responsiveness, there are other factors that can affect it. For example an application might easily do things to cause excessive repaint requests. For example, an application might do long-running computations on the event dispatch thread.

Related Topics >>