Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Java Tip 95: Load classes behind the scenes

Ebb Java performance problems with speculative class loading

By Jason Marshall, JavaWorld.com, 06/02/00

Java application and applet users commonly complain about slow launch times. Java detractors wave that fact like a red flag, claiming it's an inherent flaw in the language. There are numerous causes for that observation, some of which are being addressed by Sun (such as Swing and Java 2D performance), while others are not so easily dismissed. Until broadband network access becomes widespread, applet performance will be hindered by 56 Kbps modems. But even with applications and LAN-based applets, complex data structures still take time to set up, and classes will not load instantaneously. Those one-time costs are readily apparent on slower machines and can dampen enthusiasm for your program.

There are generally two solutions to the performance problem associated with loading your code. The first solution is to load all your code at once. That creates one giant pause, but afterward, if your user doesn't become impatient and wander off, everything works smoothly. For applets, in which I/O is the bottleneck, that means putting everything in a Jar file, which has the added advantage of reducing the total number of bytes downloaded by about 55 percent.

The second approach is to load the code piecemeal. That causes a fast startup and eliminates the execution costs for any unused code. Instead of one pause that can scare potential users away, a short pause occurs each time a new UI element is first accessed. However, that method is still undesirable because, instead of just one, every action will appear to be slow.

Most applications spend a considerable amount of time waiting idly for input from the user or another program. The program cannot transition to its next task until some critical piece of information is provided. As such, the vast majority of your application's features are hidden behind other features. For example, you almost never access the spellchecker until you've loaded the text editor. You never send data to the server until you've connected to it. You don't need to send an email to the mail server until you've written one. And, you don't need screen 2 of a wizard until you're finished using screen 1.

Your program doesn't perform tasks that the user hasn't asked it to do because that would be wasteful or result in undesired actions. So you don't even consider loading large units of code and data until they are asked for, right? Well, that depends. Strategy games and static animation and sound (movie or music playback) are notable exceptions to that rule. Those applications identify units of work they can perform ahead of time with no adverse side effects. They can (and often do) beat a hard deadline by starting the task before it's strictly needed. In the case of a strategy game, your opponent doesn't stop thinking about the board just because it's your turn, especially if there's a time limit, so why should the computer? Computers use contextual information to speculate on what tasks it will need to perform next. In a game, for example, the computer would consider what the game's rules permit you to do for your next move.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.