aspose file tools*
The moose likes Performance and the fly likes Why is the Java runtime resource hungry and slow? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Why is the Java runtime resource hungry and slow?" Watch "Why is the Java runtime resource hungry and slow?" New topic
Author

Why is the Java runtime resource hungry and slow?

Chandra Sekar
Ranch Hand

Joined: Apr 12, 2006
Posts: 94
Hi,

First of all let me make it clear that I'm not here to bash Java. I'm a big fan of the technology. In fact I believe in its potential as it is the only true 100% cross-platform runtime. Now that it has been open sourced, it has just made me happier,

However, the only factor which has been hurting me is that the Java runtime is resource hungry and has long startup times.

Consider a Adobe Flash .swf file with lot of animation, it is opened by the Flash player in a snap. On the other hand Java applets (with same amount of graphics) take several seconds to load even from the local machine and also require much more memory. With the introduction of Flex flash might become a platform of choice for RIA. Java FX has made matters worse. The loading time of Java FX is much higher than that applets themselves.

The problem with Flash Player is it not 100% platform independent. For example the latest version of player was released for Linux several months after it was released for Windows and Mac OS X.

Is there any way to make the Java runtime use less memory and start faster? If this can be achieved I feel that applets are a better choice over Flex for building RIAs. After all appearance is not everything and definitely Java is a much more robust platform than Flash.



Chandru
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The Java community has been asking for a light-weight, fast-starting version of the JVM for along time. There is work underway that will likely make it into Java 7. I think the buzzword is "consumer jvm". With luck it will have a place in the "chubby client" world of ria.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Chandra Sekar
Ranch Hand

Joined: Apr 12, 2006
Posts: 94
Even I had read the announcement of Consumer JRE. One of the primary goals were faster startup through quickstarter (warm startup) wherein the necessary files are accessed once at system startup so that they get cached by the OS. In fact this is planned to be released in Java 6 itself in 2008.

Now I feel this is not a very effective technique because it depends on the platform and different OS handle cache in different ways. Also, there is a good chance that the cached data is lost when user runs many memory intensive programs after startup before starting any Java app.

http://java.sun.com/developer/technicalArticles/javase/consumerjre/index.html

If at all this technique proves to be good, will depend a lot on how the system is used. What do other ranchers feel about this?
Chandra Sekar
Ranch Hand

Joined: Apr 12, 2006
Posts: 94
The page also says,
But the platform can preload at some earlier time, such as Windows boot or login time.


Does this in anyway mean that this facility is going to be available only on MS Windows? If something like that happens, Java would no more remain 100% cross-platform runtime.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by S.C Sekar:

Does this in anyway mean that this facility is going to be available only on MS Windows? If something like that happens, Java would no more remain 100% cross-platform runtime.


First, I don't see how it would mean that - it sounds like it's just an example.

Second, even if it would mean that, I don't see how Java would become not 100% cross-platform. It still would run on the same platforms, it's just that startup times would be little bit more different.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Chandra Sekar
Ranch Hand

Joined: Apr 12, 2006
Posts: 94
Even I hope it is just an example. But just to cite an example, SystemTray has not worked on KDE from Java 6 initialrelease till Java 6 update 2. It is promised that fixed is integrated in update 3. Is it fair for a new feature to not work on a particular environment? After all the quickstarter thing is also a new feature. So, this sentence created doubts in me.

Also, when I say a technology is 100% cross-plaform, I feel that it must exhibit similar behavior on all platforms. Having the sartup times differ on various platforms would give Windows undue advantage.

However, there is little chance that Sun would do it on Windows alone as it itself has a UNIX OS (Solaris).
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42608
    
  65
There's no way Java can work 100% the same on different platforms. Functionally - maybe (within limits), but in terms of performance and resource consumption - no. Given that the JRE contains native code, there's also no avoiding the occasional platform-specific bug.


Ping & DNS - my free Android networking tools app
Chandra Sekar
Ranch Hand

Joined: Apr 12, 2006
Posts: 94
I know performance can't be the same but the same measures to improve it can be taken on all platforms. Even Linux supports disk caching.

Though platform specific bugs are unavoidable, a new feature should definitely be thoroughly tested on all platforms. In fact the SystemTray bug was introduced in order to make it work well on Gnome. Why didn't Sun developers test it on KDE again after making it work on Gnome?

See the evaluation part at http://bugs.sun.com/view_bug.do?bug_id=6448876

Anyway, I again make it clear I'm not saying quickstarter will not be available on Linux. I'm just concerned that Sun may repeat the show.
Chandra Sekar
Ranch Hand

Joined: Apr 12, 2006
Posts: 94
Originally posted by Ilja Preuss:


First, I don't see how it would mean that - it sounds like it's just an example.


This is how it would mean that. Sun has finally decided to follow the path of other runtimes. It has decided to provide desktop improvements only on Windows.

This article https://jdk6.dev.java.net/testQS.html says,

Java Quick Starter (JQS) improves the initial startup time of Java applets and applications. JQS targets the Windows 2000 and Windows XP operating systems running on x86 (IA-32) or compatible hardware.


Even on Vista it is just turned off and the user can always enable it. But there is no quickstarter in the Linux version of the JRE. I tried the JRE build 04 of Java 6 update 5.

Now there is no compelling reason for RIA developers to choose Java. Flash is much faster to start than Java runtime. Its UI components are much cooler than Nimbus look and feel.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Now there is no compelling reason for RIA developers to choose Java. Flash is much faster to start than Java runtime. Its UI components are much cooler than Nimbus look and feel.


That is part troll and part opinion. There are probably compelling reasons to some people why they would choose Java for RIA development rather than Flex. Maybe its just a matter what what language and tools the developer is familiar with or the requirements by the client.

As far as the latter sentence above, that's your opinion. Also note that Nimbus is not a component library. It's a Look & Feel. A more accurate statement is that Flex components are much cooler than Swing components. But that's merely from an Effects POV, in my opinion. A combo box is a combo box. How fancy can it be? If you want to see what Swing is capable of go check out Romain Guy's weblog.

I'm not saying all this to say Java is the best. I'm just trying to keep things on a level playing field and making sure the FUD stays under control.


GenRocket - Experts at Building Test Data
Chandra Sekar
Ranch Hand

Joined: Apr 12, 2006
Posts: 94
As I told before I'm a Java fan. So, I'm not creating and will never create FUD against Java. At the same time I'll not go around trying to hide its defects. The world is losing the only runtime which was concentrating on all popular operating systems, providing the same improvements on all platforms. With consumer JRE, JRE is going to lose that credit.

Though I say that the default look of Flash components is cooler, I'd always use swing for mission critical RIAs though it loads a bit slower. But for any RIA which is not mission critical, Flex and Flash combination is a better choice. Maybe Java can continue to sit on the server throwing bits of data requested by Flex applications.

Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42608
    
  65
Originally posted by S.C Sekar:
Sun has finally decided to follow the path of other runtimes. It has decided to provide desktop improvements only on Windows.

No. Sun has decided to implement a particular performance improvement on a particular platform. Given that that platform has overwhelming market share, it makes sense to concentrate on it.

By the way, that document says nothing to the effect that they will definitely not implement it on other platforms in the future. Maybe it uses Windows-specific features that are hard to imitate elsewhere.

Now there is no compelling reason for RIA developers to choose Java.

Why? Java is as cross-platform compatible as it always was. Now some features are even faster on Windows. How does that make the platform less appealing?

The world is losing the only runtime which was concentrating on all popular operating systems, providing the same improvements on all platforms.

There have always been platform-specific performance improvements, and there will continue to be. This is just one example. As noted before, the compatibility of the platform remains unchanged. Also note that other JVMs (IBM, Apple) likely will not implement this particular improvement, either.

So I, too, think that there's a lot of FUD here.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Why is the Java runtime resource hungry and slow?