; Date: Thu Oct 13 2005
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.
David, There's two errors in the above. Firstly, Apple has released Java 1.5 officially, it came out the same day as OS X 10.4, it just isn't installed by default (note: Java's not installed by default with Windows either).
Secondly, the Java updates that Apple have released do include some significant performance improvements in specific areas. If Blog Bridge were affected by the performance bugs that were fixed you would see a dramatic speed up without them needing to change code at all. Despite this, I tend to agree that most of the performance improvements will have come from them improving their own code.
Posted by: ajsutton on October 13, 2005 at 04:34 PM
Okay, perhaps I hadn't paid as much attention to what Apple was updating ... however I'm still on 10.3.9 (haven't moved to 10.4.x yet) so my system doesn't have 1.5. I know there has been a developer release of 1.5 for 1.3.x but I didn't bother retrieving/installing it. -- David
Posted by: robogeek on October 13, 2005 at 04:42 PM
David, thanks very much for noticing. I have some further comments in our blog: http://www.blogbridge.com.
Posted by: pitosalas on October 13, 2005 at 05:25 PM
Pito, that's a good point on your blog entry. Profiling GUI application performance is rarely easy. I shouldn't have called it "simple" .,.. Clearly, though, profiling and optimization can give tremendous benefit.
BTW, I just installed blogbridge on my Linux system here at work. It was real nice being able to retrieve the same set of subscriptions I have at home. That's one of the interesting features which may be unique to blogbridge, that the subscription list is stored on the blogbridge server. I wonder, though, whether it passes on knowledge I've read an article from one system to the other systems I'm using.
Posted by: robogeek on October 13, 2005 at 06:15 PM
David, yes BlogBridge remembers what you have already read when you save your subscriptions to the service and restores the marks on the other side when you do full or only-load sync. :) If you have a habit to close application when you finished reading (do not leave it spin all the time in background) then, most probably, you will like an automatic synchronization feature which will sync-in on startup and sync-out on exit to keep your workplaces consistent at all times.
Have fun and, certainly, thanks for mentioning us!
-- Aleksey Gureev
Posted by: spyromus on October 14, 2005 at 12:53 AM
ajsutton: This is not the final version of Java 1.5 that was released. You can tell not only because you find it on developers web site but also because it is awfully buggy (especially when it comes to pictures and glasspanes). I use Java 1.5 on my Powerbook as my default Java environment but I wouldn't advice anyone to do the same unless you really need 1.5.
Posted by: gfx on October 14, 2005 at 01:57 AM
Here a statement from Alan Samuel on firstname.lastname@example.org: All,
I know there has been a lot of discussion regarding Apple and Java 1.5, so I thought I would shed some light onto the situation. One of the main reasons that Java 1.5 is not yet the default on Mac OS X is not because it is not ready for general use. We are extremely concerned about backward compatibility between versions. In general Sun has done a very good job at this. We have designed our Java versioning system so that everyone has access to Java 1.5 without the risk of a possible regression for already shipping applications and applets. Once we know the risk is minimal, we will make Java 1.5 the default. We realize that this has created an inconvenience for developers, but our mutual customers are also part of the equation and we need a solution that works for both.
How do we know that are not ready to make Java 1.5 the default? Firstly, we have had very few bugs filed against Java 1.5 (apart from it not being the default). We can not gauge its quality from the lack of feedback. Either it is extremely solid, or people are not using it. We are moving in the right direction: the upcoming release of Java 1.5 will be a checked sofware update, will be downloaded by millions of users, but not yet the default Java on Tiger. For the following release, it will again depend on the feedback we receive from you.
Posted by: lordy on October 17, 2005 at 12:59 AM