| Java menu knowledge base
Speed issues
Things to be aware of while designing with applets
Our navigation applets work fast and when we
programmed them we ran precise millisecond counts and
memory analyses at all the crucial stages, optimizing
and reconceiving vital operations again and again to
extract a maximum of performance.
However - designing your own implementation of our
applets is like designing a webpage. While our tools
may make it equally easy for you, you also have the opportunity to
fill our applets with huge graphics, wrongly configured
indices and incorrect parameter settings - if you wish.
Just as with an over-ambitiously designed webpage, so
with our applets you can make excessive demands of the
network environment and your visitor's computer. For this
reason you must take care to
get the most out of your applet while saving on bandwidth
and processor time.
Browser meets applet, and then...?
When someone says "huuh, the applet's slow", there may be dozens
of factors affecting the speed, many of which actually have nothing
to do with the applet. To cure the problem, you have to understand
the causes. This is a chronological list of all the processes
gone through by the browser when it hits an applet.
1. Starting the JVM. The JVM is a part of your browser
that sits on your own computer, waits for an applet, and interprets
the tiny applet code and makes the applet behave like a big normal
programme. Normally the JVM is not started when you start your
browser. It is started separately the first time your browser finds the
applet tag in an HTML page. It then remains active for the rest of
the browsing session.
2. Creating a grey box. The browser then creates a grey
box on your computer screen for the applet to go in. (NB: Netscape
6 also displays scrolling messages in the grey box - these are created
by the VM, not the applet).
3. Downloading the applet. The browser then fetches
the applet file from the server. Note that up until now the applet
is not running, nor is it even present on your computer.
4. Starting the applet. After the whole applet has
been fetched from the server, the applet then initialises and
runs. The browsers frequently report this fact in the status
bar window, and the applet may start to do things such as
repainting the grey box with a new colour, starting
a countdown or displaying a loading message.
5. Fetching applet resources. Many applets have
separate external resources, such as graphics or text files
which they require in order to run. These resources have to
be fetched from the server just like anything else. So the
applet adds its own server requests to the list of requests
already made by the HTML page. Note that the HTML page started
first, so it gets its resource requests in the queue first.
If the HTML page wants a lot of stuff (e.g. graphics) from the
server, the applet is going to have to wait a long time for
its resources to be delivered.
6. At this point the applet finally gets a chance
to start running normally and stop waiting for all sorts
of other things to happen.
Faster JVM loading?
The JVM is the part of the browser which interprets
java code and turns it into something the computer can understand.
It is part of your browser and only starts when an applet tag is
met during a page download. The JVM then stays resident until you
close your browser, which means that if you meet any more applets
during the same browser session, they will appear to load faster
as the JVM doesn't have to be started.
The JVM's tend to be rather slow at loading. A benchmark value you can use
is that on a standard PC (let's say a poorly configured
133 MHz Pentium with 32 MB RAM), the Netscape 4 JVM needs about
8 to 10 seconds to start. Microsoft's JVM starts a bit
faster.
Note that when the JVM starts, the applet may still be
halfway across the world (on the server), so you really can't
blame an applet for the slow JVM. There's only one way to speed
up a JVM, and that's to run down to your computer store and upgrade
your processor, RAM (and perhaps your whole hardware), although
you should perhaps ensure that your system is properly optimized
for speed first.
While we're on the topic of java interpreters, the OS can also make
a difference to what kind of performance you get out of your
java interpreter. Macs have consistently received the lowest
scores in general tests of java interpreter performance, while W95
PC's always get the best scores (that's independent of our applets,
applying to java in general). Other OS's come between these
two extremes.
The ugly grey box
The grey box indicating an applet loading is one of the irritating things
about java. There is no really good way to get rid of it completely,
although the time it displays can be minimized. The grey box is actually
created by the browser before the applet is downloaded, which means
that at first, it is the browser that is responsible for the grey box, not
the applet. While the applet is still being transferred from server to
client, there is no way that java programming itself can do anything
about the grey box. And neither Microsoft nor Netscape have yet introduced
options into their browsers which allow you to change the greyness of
the applet box during download.
With our own applets, as soon as the download is completed, one of the
first things the applet does is to repaint the grey box with the colour
you specify as the background colour. There is then a further delay
while the applet fetches the resources (graphics and menu) from the server.
If you do not specify a background colour, your site visitors will have to
endure the grey box for a while longer.
Infinite system resources...
...are not yet available to all of us most of the time.
The browser and the various technological gadgets that operate
within it are allocated a specific quantity of resources. By the
time you have a browser and its java interpreter running on
your system (and a few plug-ins and other applications), there
isn't much room left. And even if you have a mega-machine, java
doesn't yet run that fast. No programmer can yet achieve with
java the kind of performance that one would normally expect from
a state-of-the-art computer game of the 3D full detail action
variety.
Executable code and other web page gadgets compete for only
a relatively small reserve of system resources. For example,
if you
have huge javascripts, these can take resources away from the
applet (and javascript seems to be very wasteful in terms
of resource usage - watch out!).
The same applies if you are trying to run several applets.
Fewer resources means performance loss, and this can, on occasion,
be quite considerable.
You should also be aware that when you leave a webpage with an
applet, Netscape does not remove the applet. The applet continues
to take up resources. When Netscape has a total of 10 applets
somewhere inside it, it then begins to "prune" them, which means
partially recovering resources. That means that if your site visitors
wander through a sequence of pages with different applets on them (or
even new instantiations of the same applet), an increasing
amount of resources are being used up all the time. And that means
a progressive deterioration of performance. Moral: if you care
about your site visitor, use applets
and other gadgets sparingly and only as necessary.
|
|
