Skip to main content

Please keep working on client-startup time and footprint

16 replies [Last post]
linuxhippy
Offline
Joined: 2004-01-07
Points: 0

Hello!

I work for a company that writes client and server software in java.

From client point of view there isn't soo much difference between 1.3.1 and 1.5.0 - both takes on mid-class computers about 6-10s when started up the !!FIRST!! time.

The problem is that the lead-developer that worked before me at this company only wrote VB6 (argh!) programs and now my new java-programs are measured against those vb-programs performance and well, suck.
With performance most people seem to mean startup-time and its really hard to tune stuff that is done outside of your code ;-)

I know that there has been a lot of work spent on tuning startup-performance and it would be really great if you could continue your work on this topic.
Overall performance is great since 1.3 and since 1.4 even java2d performance is excellent (thanks for the ogl pipeline!!!).

So please keep working on one of the last bottlenecks of java performance.

lg Clemens Eisserer

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
murphee
Offline
Joined: 2003-06-10
Points: 0

>PS: Another thing which I do not understand is, why java
>has no assembly cache at all. Every time the applikation is
>started up all the same classes are jitted every time...

Refer to this Javalobby discussion
http://www.javalobby.org/forums/thread.jspa?threadID=15812&tstart=15

It has a couple of good explanations on why caching JITed
code is not done yet.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

thanks for posting this link!

It seems JRockit is quite an impressive JVM - sad that its targeted for server-use :-(

sutanu
Offline
Joined: 2003-06-10
Points: 0

I did a simple test with jre150 (Client VM) to get a rough idea on how many classes it takes to run a swing client app.
I ran java -verbose:class -jar SwingSet2.jar on Windows. After the app loads clicked all the toolbar buttons before I stopped the app.
I got the following stat on number of loaded classes:

Classes loaded from:-
SwingSet2.jar [b]124[/b]
rt.jar [b]2068[/b]

Out of all classes from rt.jar:
java.awt [b]228[/b]
javax.swing [b]839[/b]

Someone might argue that all those classes are necessary. But it looks like class bloat to me. It does not surprise me why even with all the hotspot improvements (e.g. [i]class data sharing[/i]), the startup time and footprint are still not within acceptable limit.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

This is one of many reasons why we do not use Swing.
The initial client was based on swing (on 1.1 with the swing 1.1 bundle) and while startup on 1.4 took several seconds it was unacceptabel slow on 1.1 browser machines.

We now use LwVCL which provides nearly everything we need, and it starts up fast and does use only a few classes.
E.G. our whole client app loads not more than 800 classes during whole execution, although its rather complex.

But now you can see that 1.4.2/1.5 has a much higher startup overhead that 1.1 had - the old 1.1 jvms with their ugly JITs, their slow class-loading and bad garbage clollectors start much faster than 1.5 - although 1.5 has so many advanced features like CDS and so on.

lg Clemens

dog
Offline
Joined: 2003-08-22
Points: 0

A solution others probably already have thought of is to run a VM as a service on the machine which can run multiple programs (and keeps itself clean when not running anything to use the minimum resources possible).

At least this option would be good. Dumb user won't notice a service is running (as long as it doesn't suck up more than a couple of megs of RAM). Expert user can turn it off if he doesn't like it and load on demand.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

As I already said, please do not misunderstand me.

Its just a general point that needs attention in future - not a specific problem.
Thats why this forum is called "what developers want" and not "please help developers".

Its just my whish that startup-performance should be further improved.

lg Clemens

PS: Preloading is in my eyes very ugly and dirty. This should be investigated if java-developers really fail to make it faster any more...

zander
Offline
Joined: 2003-06-13
Points: 0

The simples solution for this problem is to use a splashscreen.

I made one that is open source; so just download and use. Its part of a larger project that is mostly Swing, so you might want to get that one class from the jar :)

I see a splashscreen in under 1 second on 1.4.2 on an 800Mhz machine, so this should be a great timesaver.

See:
http://uic.sf.net/
http://uic.sourceforge.net/api/uic/widgets/Splash.html

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

1.) A slashcreen does not make startup-time shorter

2.) The spash-screen appears 1s after start if JVM was started before or is just running.
The problem I think which should be adressed is startup-time when java was not loaded before.

Please do not misunderstand me, I so not have a problem with MY application & startup-time. Its just in general that java-apps need a long time to start up if the jvm has not been started before.

zander
Offline
Joined: 2003-06-13
Points: 0

> 1.) A slashcreen does not make startup-time shorter

The user surely percieves it as shorter.

> 2.) The spash-screen appears 1s after start if JVM
> was started before or is just running.
> The problem I think which should be adressed is
> startup-time when java was not loaded before.

It seems you misunderstand where the loading time of your application comes from.
Starting java from a command line is intant and takes absolutely no time at all.
Starting an application means loading all the classes that it needs, this is the part that takes a lot of time.

Please actually try the splashscreen to see what I mean since you are assuming that starting java, and then showing the first screen is the same thing, it is not.

The 1 second I posted before is from the moment I press enter on a command line where no java has been started before.

The comment on 'not started before' makes me think you are talking about a java instance inside the webbrowser. If you are, then just about everyone here seems to have misunderstand your request.
Also, startup time of a JVM inside (for instance) IE has very little to do with startup time of Suns Java, so you are on the wrong forums.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

1.) Well, most of the startup-time comes from loading and initializing the native libraries and their java-counterparts.
If you only invoke command-line java nothing has to be inited "really".

2.) Yes, I also talk about java-applet startup time. But as mentioned above I do not talk about msjvm or netscape's jvm, because at leats netscape is amazingly fast up and running, I talk about java loading-speed in general and also the startup-timeo of the java-plugin itself.

lg Clemens

PS: Does anybody know why java has not Assembly cache?

smartinumcp
Offline
Joined: 2004-09-07
Points: 0

What I've done, for the certification one too, is separate my main class from the heaviest components for Swing/AWT clients. That reduces the initial hit for the class loading and allows sub-second startup time vs seconds when it unnecessarily loads megs into memory. The ides have gotten better in helping with that and I think people are starting to accept the concept of not using .* for includes.

Windows wins in that regard because they always have the dll in memory usually. Part of why it takes so long for the friggin' machine to start up.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

1.) Well if you seperate your main-class from any awt-stuff its nice - however I do not see the sence.
The user will see your application is started up fully, when the gui is up&ready.
Btw. I do not use Swing at all at the moment, because its not 1.1 compatible - but thats another story.

2.) Using *.* as import isnt bad at all - the compiler (javac not jit) will lookup all needed classes and write its imports itself. so importing only needed classes just bloats your source.

3.) I know that windows wins because of the fact that dlls are already loaded and shared.
I also that its hard to compete which such systems, but tell a customer why your app needs 15s to start up on his 500mhz machine while the old VB6-app was up in 2!
Tell him about classes, JVM and so on - he will just laught and buy nothing!
Or applets - Many people hate applets just because their browser locks for 10s while jvm is loading (and with mozilla it even asks for proxy-configuration - argg!)

Thats the fact why I asked the mustang-developers for improving startup-time furthermore, I know thats hard but VERY important for both java itself and apps written in java.
A very big reason why java has its repotation for being slow is because it (still!) starts up slow.

lg Clemens

jwenting
Offline
Joined: 2003-12-02
Points: 0

Are you still using JRE 1.1 for your clients yet complaining about startup times in modern JVMs?
Hardly fair I'd say.

You're probably letting your users wait and wait and wait looking at a blank screen when that VB application likely shows a splashscreen and maybe a progress bar.
Such things give users the impression of a quickly starting application.
You can do the same in Java and there will be little difference if you program it smartly.
As said, refrain from loading huge amounts of classes at initial startup, instead load them only as needed.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

I have to support 1.1-JVMs to customers that want just to use our program with their browser - not downloading 8mb java-installation.
I am only the developer and I have to do what management tells me but I can understand this descision.
Sometimes we switch at runtime, e.g. to use VolatileImage for backbuffer starting with 1.4.

The funny thing is that even the old Symantec-JITs included in Netscape-4.7 start much faster than 1.4.2 on older machines, although this compiler is known to load nearly all ever needed classes at startup and compiles all of them to native code.
They are up and running in 3-5s on our 500mhz test machine.
Of course the run code much slower, but if you tune your code to not to stress the GC to much I would say that from the "feel"-standpoint this old JVM "feels" simpyl best.
Up in next-to-null and very resource sensitive.

I already look at needed classes only and I also display a startup-screen. However startup-time is 15s (on P3-500) and IT IS NOT MY FAULT!
I dont do crazy initialisation nor do I load to much classes (700 after startup), its also not every time.

Its just the first time the jvm starts up - no dlls are in cache, so slow disk-operation is performed.
I know its hard to tune this, but I think there should me more investigation on this topic.

lg Clemens

PS: Another thing which I do not understand is, why java has no assembly cache at all. Every time the applikation is started up all the same classes are jitted every time...

Message was edited by: linuxhippy

smartinumcp
Offline
Joined: 2004-09-07
Points: 0

I've seen some significant speedup by limiting the amount of imports for my swing/awt clients. You may also want to run the -verbose command to see how many classes you're loading.

zander
Offline
Joined: 2003-06-13
Points: 0

> I've seen some significant speedup by limiting the
> amount of imports for my swing/awt clients. You may
> also want to run the -verbose command to see how many
> classes you're loading.

In order to not confuse people;
loading classes takes time, you can compare 1 class with 1 dll in concept.
The actually used classes take time to load, but only one time per JVM.

Having import java.util.*; instead of 10 seperate imports for specific classes changes absolutely nothing in loading time.