gerrards8 @yahoo.com said:
With today's *average* personal/business desktop computing power, do you
consider Java based client applications to be slow? (to remain pure,
let's just concentrate on Swing based apps)
The two Java applications I think of when I think of "Slow Java
Applications" are Eclipse and JEdit, and occasionally Azureus.
The only native program that I know of that does something of similar
complexity to Azureus is eMule, and they're about the same speed. That is to
say, the bottleneck is probably not CPU power but rather disk I/O and
network I/O.
The only native program that I know of that does something of similar
complexity to Eclipse is Visual Studio. Actually, Visual Studio does far
less "real time code analysis" (e.g. detecting errors as you type,
quickfixes, intellisense, etc.) The two are of comparable speed, with
Eclipse being a bit faster while actually "running" (might be an illusion
from it continuously pre-compiling, as opposed to VS's "compile when the
user says to compiler"), but Eclipse takes longer to load and quit.
The only native program that I know of that does something of similar
complexity to JEdit is TextPad. TextPad does quite a deal less than JEdit,
but TextPad is blazing fast compared to JEdit. So here's a situation where
Java might actually lose out due to performance; whether a user prefers
JEdit or TextPad would depend on whether they are willing to wait longer in
exchange for more features or not. Maybe someone should optimize JEdit (be
sure to profile first!), or write a clone of TextPad in Java, with all the
extra features in JEdit stripped out for performance?
For every other Java application I've used, speed was not an issue. As a
specific example, JDiskReport (
http://www.jgoodies.com/freeware/index.html)
shows you free disk space on your harddrive. The equivalent native program
is DiskSpacePlus (
http://www.softwhile.com/product_dsp.html). I find
JDiskReport actually "feels" faster, but this probably due to JDiskReport
using a seperate thread to scan the disk drive than the one drawing the UI,
while the DiskSpacePlus application seems to be using the same thread for
both (i.e. while scanning the disk, it does not repaint the window or
responds to mouse clicks).
So, IMHO, Java is "fast enough" except in the domain of plain text
editors.
If so, at what point (in time and/or JVM release) did this performance
issue become a non-issue?
Maybe I was a late adopter, but I've never encountered a Java program
that was slow for which there existed a noticeably faster native program
(except for the JEdit vs TextPad situation mentioned above). I'm told there
was a point in history during which Java was dog slow. I guess back then,
people didn't bother releasing many Java applications because it was so
slow, which is why I never really encountered any such applications. When
Java sped up, more applications were released which were written in Java,
and so when I encountered them, I never experienced this "slowness" that
some people claim to be a property of Java.
Please base you reply on desktop computers that can be purchased in your
market today, clean of all the infestations of unnecessary memory resident
and background processes that are normally pre-installed on commodity type
Win systems.
I'm basinc my reply on my own experiences, which is composed mostly of
my own personal computer.
- Oliver