Performance on today's desktop

[gerrards8]

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)

If so, at what point (in time and/or JVM release) did this performance
issue become a non-issue?

If not, is it the application architecture or the JVM (and its libs,
i.e., Swing) that's behind this lag in performance?

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.

 

[gerrards8]

That was very bad!

Please _revise_ question to:

With today's personal/business desktop computing power, do you consider
the performance of Java based client applications to be satisfactory?
(to remain pure, let's just concentrate on Swing based apps)

If so, at what point (in time and/or JVM release) did this performance
issue become a non-issue?

If not, is it the application architecture or the JVM that's behind this
lag in performance?

Please base you reply on desktop computers that can be purchased today,
clean of all the infestations of unnecessary memory resident and
background processes that are normally pre-installed on commodity type
Win systems.


Sorry for the confustion..

 

[Monique Y. Mudama]

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)

They're not blazingly fast, but they're not slow. I guess it depends
on what you mean by slow. Slower than native? User would say that
it's slow?

If so, at what point (in time and/or JVM release) did this
performance issue become a non-issue?

I think it had less to do with the JVM than with improvements in
hardware over tmie.

If not, is it the application architecture or the JVM (and its libs,
i.e., Swing) that's behind this lag in performance?

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.

Why? That's not a realistic expectation of a user machine. User
machines were probably purchased a few years ago and are almost
certainly infested.

 

[elektrophyte]

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)

If so, at what point (in time and/or JVM release) did this performance
issue become a non-issue?

If not, is it the application architecture or the JVM (and its libs,
i.e., Swing) that's behind this lag in performance?

I've been using the IntelliJ IDEA Java development environment, a Swing
app, for about two years and it's fine on average to high end PCs. At
first it seemed a little slower than native GUI applications, but
definitely useable. I never had any problem with it's speed. Since
about a year ago, the difference has not been noticable; there's been
no "lag".

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.

Most computers I work with are loaded with lots of background
processes. Actually, one of the guys has noticed that it doesn't play
well with the Novell Groupwise client for Windows, come to think of it.
But I never noticed that problem.

In general, my sense is that with today's machines, and improvements to
Java, Swing application performance is acceptible. You could easily try
it out for yourself by trying some of the apps found here:

http://java.sun.com/products/jfc/tsc/sightings/

E

 

[Oliver Wong]

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

 

[Thomas Hawtin]

The two Java applications I think of when I think of "Slow Java
Applications" are Eclipse and JEdit, and occasionally Azureus.

Eclipse is not a Swing app.

JEdit is incredibly badly written and is slow because of its
"optimisations" (what else would you expect from a GPL program</troll>).

When I think slow application, I think Thunderbird, Firebird, Opera and
gedit.

Tom Hawtin

 

[elektrophyte]

I'm told there
was a point in history during which Java was dog slow.

I think that's true. When I started programming in Java in 2000 I tried
to use Sun's "Forte" IDE which was written in Java. On a 550 mHz PC
with 256 MB or RAM it was indeed miserably slow.

I never experienced this "slowness" that
some people claim to be a property of Java.

I can think of reasons someone would choose not to develop a desktop
app in Java. However, the slowness issue has been pretty much resolved.
It's too bad the Java platform can't shake the reputation of being
slow, even though it isn't anymore.

E

 

[gerrards8]

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).

You bring up great examples, and I totally agree with them.

But, let's look at similar examples from the other side.

What about office type applications (Word, Excel, Power Point)? Only
one I can think of is ThinkFree (not sure if they include an API to
integrate with their product). Perhaps there is only one choice of a
decent HTML or PDF renderer in the market, and the price is way up!
Very few Email and SQL clients (dbVisualizer rocks!). Hardly a fully
functional reporting tool that would meet Crystal Reports or MS Access'
reporting features plus ease/speed of report design, and the list goes
on...

I do believe the speed has been a non-issue, even with Swing, for 2 to 3
years now but don't understand why desktop Apps (free or for $) are very
rare, specially the kind that can integrate and enrich other Java
desktop Apps.

 

[Roedy Green]

When I think slow application, I think Thunderbird, Firebird, Opera and
gedit.

Why are browsers slow?

1. because servers are slow

2. because transmission is slow

3. because of errors causing retransmissions?

4. because of having to parse unclean markup and make sense of it
anyway.

5. because HTML is so designed that you need the entire document
before you can completely nail down the layout.

6. something else.

 

[Roedy Green]

I do believe the speed has been a non-issue, even with Swing, for 2 to 3
years now but don't understand why desktop Apps (free or for $) are very
rare, specially the kind that can integrate and enrich other Java
desktop Apps.

Same reason you don't see non-java such apps. To compete you have a
lot of catching up to do. The other reason is Java is very easy to
decompile. Companies like to keep they code obscure.

 

[Chris Smith]

I'm wandering into the middle of this, but...

Why are browsers slow?

1. because servers are slow
2. because transmission is slow
3. because of errors causing retransmissions?
4. because of having to parse unclean markup and make sense of it
anyway.
5. because HTML is so designed that you need the entire document
before you can completely nail down the layout.
6. something else.

It varies. 1, 2, and 5 are common. I'd never dream of 3 or 4 making
any difference at all.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Thomas Hawtin]

Why are browsers slow?

1. because servers are slow
Rarely.

2. because transmission is slow

I don't need to use my 33.6 kbps modem anymore, since digital has become
available across this densely populated country.

3. because of errors causing retransmissions?

Hope not.

4. because of having to parse unclean markup and make sense of it
anyway.

I don't think that's really a problem, although it can't help with
maintenance.

5. because HTML is so designed that you need the entire document
before you can completely nail down the layout.

That hasn't really been a problem since 1997.

Kind of related is overly long HTML. I believe display times tend to
dominate, but pages with loads of stuff going on appear to be a bit
slow. http://bugs.sun.com/bugdatabase/index.jsp as an example. Sites
using JavaScript to animate are just evil (particularly if you have a
large number of tabs open).

6. something else.

Mostly it's down to the GUI responsiveness. I used Firefox briefly after
Mozilla until Opera came to my rescue (which isn't half as bad). Firefox
is truly amazing. Open a new page and it locks up for a while. Any
operation and goes into vegetive mode for a while. Back on Mozilla I
once timed opening the history window taking one and three quarter minutes.

For Opera the RSS reader is really irritating. Okay, some of the
irritation is feeds that don't actually include the article inline. Take
ages to move from one article to the next. Above 140 ms (or thereabouts)
response time user interfaces become disconcerting.

For long pages, which have their visible portions displayed perfectly
accurately it inhibits progress by giving a busy cursor. Everything is
in fact ready to go, but Opera is putting up stop signs.

Also the usability of the search impacts on actual performance. I
haven't noticed any incremental search, so finding keywords becomes an
arduous task.

It could do better switching between tabs isn't particularly clever.
Okay, updating the page may take some time, but that's no excuse not to
update the tabs.

And they swap massively, but what doesn't.

Tom Hawtin

 

[gerrards8]

Same reason you don't see non-java such apps. To compete you have a
lot of catching up to do. The other reason is Java is very easy to
decompile. Companies like to keep they code obscure.

OpenOffice is gaining quite a momentum worldwide, even here in the U.S.
where MS has every government branch in hand. The state of
Massachusetts is dumping MS Office in favor of OpenOffice due to its
support for OASIS' OpenDocument as its default format (XML, but the
right way!); and that's an Open Source software, whether the free
version or the commercial one (StarOffice).

Last I heard, Novell is also working on porting Evolution to Windows –
Yet another “in your face” competition to Microsoft, and again,
open-source (at least partially, not sure of its release 2).

JetBrains (IntelliJ), Borland, Sun, Oracle, IBM and many others have
done well selling Java based commerical software despite the risk of
decompilation. They're threatened by free software, not open source.

 

[Scott Ellsworth]

OpenOffice is gaining quite a momentum worldwide, even here in the U.S.
where MS has every government branch in hand. The state of
Massachusetts is dumping MS Office in favor of OpenOffice due to its
support for OASIS' OpenDocument as its default format (XML, but the
right way!); and that's an Open Source software, whether the free
version or the commercial one (StarOffice).

Java is not a perfect fit for the desktop, which means that developers
have to do more legwork to generate an application that 'fits in' than
they would if they used the platform native tools. I find that
additional work is not all that rough, usually, but if it is not done,
then the app stands out as a turkey.

It is the failure to do that final fit and finish pass that makes most
Java application kinda bite. Those that have had that done seem to work
pretty well. (I speak both of the commercial ones, and the custom apps
that our group writes.)

One good litmus test for whether the company 'gets it' is whether they
produce a Mac version. A linux version is also a decent predictor, but
the platform is close enough to Windows in look that it is not as clear.
While engineering their Mac release, they usually find a lot of 'well
how does Windows do it' problems, that then get addressed early in the
product life cycle.

OpenOffice has made the classic mistake - waiting until their app is
mostly done before considering a Mac build. Thus, any problems will be
found too late in the development cycle for them to consider fixing.

NetBeans, on the other hand, has done a fairly good job of looking at
what it will take to make their IDE Mac-like. They still have a ways to
go, but they are making appropriate changes.

IDEA has been doing this for a while, and is correspondingly far ahead
on that score.

Producing a Mac version will not insure good quality at the other end,
but it will mean that you question your platform specific assumptions
early in the process, and figure out your growth path.

Scott

 

[gerrards8]

Java is not a perfect fit for the desktop, which means that developers
have to do more legwork to generate an application that 'fits in' than
they would if they used the platform native tools. I find that
additional work is not all that rough, usually, but if it is not done,
then the app stands out as a turkey.

Personally, I don't subscribe to the “fit in” notion as long as the App
behaves in a generally accepted manner (UI). However, I would admit
that I'd be a lot happier if my App does “fit in” without doing any
platform specific coding, nor relying on third party libraries for that
(IOW, JRE's responsibility).

However, the question I wish to ask is that how many end users (home or
business) out there make their software purchase decision based on the
“fit in” criteria? I'm confident that if Adobe were to offer their
Photoshop or even PDF viewer in, say Java/Swing straight up (it's a
hypothesis), they would still be the market leader of such product
segment, and that's due to the overall quality and value of their product.

In the case of Mac, Apple would benefit greatly if Java desktop Apps
would boom, just like they're benefiting from free Unix/Linux based
software out there. IBM is constantly knocking on developers' doors to
market Java solutions on IBM high end servers; perhaps Apple has better
plans.

 

[steve]

Personally, I don't subscribe to the “fit in” notion as long as the App
behaves in a generally accepted manner (UI). However, I would admit
that I'd be a lot happier if my App does “fit in” without doing any
platform specific coding, nor relying on third party libraries for that
(IOW, JRE's responsibility).

However, the question I wish to ask is that how many end users (home or
business) out there make their software purchase decision based on the
“fit in” criteria? I'm confident that if Adobe were to offer their
Photoshop or even PDF viewer in, say Java/Swing straight up (it's a
hypothesis), they would still be the market leader of such product
segment, and that's due to the overall quality and value of their product.

In the case of Mac, Apple would benefit greatly if Java desktop Apps
would boom, just like they're benefiting from free Unix/Linux based
software out there. IBM is constantly knocking on developers' doors to
market Java solutions on IBM high end servers; perhaps Apple has better
plans.

apple never gave a shit for java, and they still do not.
anyone using os9 could see that , long before osx was released, 1.1.8 was the
de-facto standard on apples os9 for 2 years , whilst everyone else was on 2.x
same on osx now. with this built in java crap, we lag by several major
revisions.
I'm working with apple now on a bug that stops you printing ANY documents
from java , if you send more than 1 document. it is reproducible only on osx
and on all JVMS including 1.5.
They fixed it on their high-end machines,(>900mhz) but not on the "low end
stuff" and it's now been over 3 months. ( its being "verified", same as my
other bugs in their java implementation, being verified for over 2 years"
(sounds like sun))

not to mention their shitty implementation of the java tool box.

When printing documents using:
PrintServiceAttributeSet printServiceAttributeSet = new
HashPrintServiceAttributeSet();

// aset.add(MediaSizeName.ISO_A4); //does not
work crashes or hides printers

// aset.add(new Copies(numberOfCopies)); does not
work

does not EVEN have the code implemented for setting number of copies page
size etc. despite it being in the 1.4.x spec.

yes i still have to loop to print multiple copies, and hope my printer has
the correct size stock.
Apples answer is "duplicate bug- previously reported", no shit , you mean i'm
not the only person trying to print documents.


Even me telling you this means i can be butt fucked under their
non-disclosure agreement.


Steve

 

[Scott Ellsworth]

apple never gave a shit for java, and they still do not.
anyone using os9 could see that , long before osx was released, 1.1.8 was the
de-facto standard on apples os9 for 2 years , whilst everyone else was on 2.x
same on osx now. with this built in java crap, we lag by several major
revisions.

I beg to differ.

I have met the people involved, and they do care. They do not, however,
have unlimited resources, and the resources they get are based on what
the developer community and sales force demands. There was not
sufficient call for an OS 9 1.2 VM to justify the rather amazing amount
of work, given that OS X was their future. Had they failed to move to
X, they would have ceased to exist.

Outsiders could do a Java port, were they interested, but from what I
have heard, Sun does not give a damn about the platform, and it is not
clear whether Apache's project is going to produce a working JVM.

Scott

 

[steve]

I beg to differ.

I have met the people involved, and they do care. They do not, however,
have unlimited resources, and the resources they get are based on what
the developer community and sales force demands. There was not
sufficient call for an OS 9 1.2 VM to justify the rather amazing amount
of work, given that OS X was their future. Had they failed to move to
X, they would have ceased to exist.

Outsiders could do a Java port, were they interested, but from what I
have heard, Sun does not give a damn about the platform, and it is not
clear whether Apache's project is going to produce a working JVM.

Scott

We are not talking about resources to develop some mickey mouse project
needed by 50 people, we are talking about making sure the basics work.

you consider printing is not basic enough?
how about correct language support?

 

[Scott Ellsworth]

We are not talking about resources to develop some mickey mouse project
needed by 50 people, we are talking about making sure the basics work.

I am not pretending that their implementation is perfect. I am saying
that 'Apple does not give a shit for Java' is in direct opposition to a
team of over a dozen people paid to write it, with two new hires
recently, and an open job req. The team is bigger than the Core Data
group was through most of Tiger development, IIRC. Heck, the shared
archive feature of Apple's 1.4 VM got moved into Sun's 1.5
implementation, so they are doing real and original work. This is money
being spent, and thus Apple clearly does care.

The test of whether the 'basics work' is the JCK. You cannot ship if
you fail to pass, so if something is missing, bug Sun to add it to the
JCK.

As far as my earlier argument about missing Mac libraries on the Java
side, let me rephrase. Apple's resources are not unlimited, and thus
they have to be allocated. If you want an API to have a Java
implementation, you have to convince Apple that it is worth spending the
time and treasure. That convincing comes through the developer
community and through what sales reports to them. I find sales awfully
powerful in that discussion, given that the java team is funded from the
same $129 OS sales that drive Cocoa and the core OS.

you consider printing is not basic enough?

Apparently Sun did not, as it did not make the JCK.

I just read your earlier post again, and the release notes. Given that
they did fix some printing bugs, they obviously tested printing. Given
that your bug is still there, they did not test it well enough. I would
be surprised if your bug was a known one on ship day, as it did not make
the release notes.

how about correct language support?

Correct language support? If, by this and 'we lag by several major
revisions', you meant that we have 1.5_02 when 1.5_05 just shipped,
well, they do have a preview of 1.5_04 out now. Or would you rather
they held back for another few weeks to ship _05? (I, personally,
wanted _04, so I could get the NetBeans folks to bring up their profiler
now.)

Sun could always ship a VM for the Mac, but we saw how that worked last
time. Maybe the Apache group will succeed at making a better VM than
Apple, but again, I am not so sure that will work.

Scott