HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

You've just finished up that Java program you've been working on for a while. You sit back in your chair and feel proud of yourself. It's now time to show your finished work to the boss. Half an hour later he calls you into the office. "What's this?" he asks as he holds up one of the floppies that you proudly gave him just a little while ago. You try to hide the confusion and fear in your voice as you answer. "It's the application I've been working on. It's finished, and I just wanted you to have a look at it." He gestures you to his side of the desk. You watch him open the application on his machine. It opens just fine, but as soon as he begins to use it, it slows down, way down. Almost to a complete stop. "I thought it was hanging up my system," he says to you as he munches his sandwich, "but after I came back from getting my food, it started to run - a little bit, anyway." He gives you an encouraging word as he puts his hand on your shoulder to escort you to his door. "Fix it," he says as he closes the door behind you.

You just don't understand. The application runs just fine on your 300 with 128 megs of RAM. Why is he still running that ancient 166 with only 16 megs? Why should you adjust your applications for people still running machines made when the Romans invaded Carthage? You calm down a little bit and begin to think. It makes sense that a successful program will run on many different machines. Not everyone has a 300. You need to adjust the program so it can run smoothly on "lesser" processors. You need to find a way to pinpoint exactly where the application slows down.

In the old days, this was quite a challenge. You would have to decompile the code, go through it step by step and see if you could identify the problems that way. This was a tedious process that led to lots of banging on the desk and cursing. You don't have time for this. You need a quicker, easier way to do this. You need Visual Quantify!

Visual Quantify is the new application that lets you identify, track and even fix performance "bottlenecks" in your applications. It is amazingly simple to install and use.

We found Visual Quantify to be very simple to install. Installation was no more difficult than any of the current popular game software. If you're using Microsoft Developer Studio 97, VQ automatically integrates itself into that application. The next time Studio is opened, the VQ menu and toolbar are visible. This makes it possible to utilize VQ's features without leaving your development environment.

Using Visual Quantify
When VQ is first opened, it offers three options:

  1. Run will pull an application through and begin instant analysis.
  2. Open will pull up any files saved in VQ format (*.qfy).
  3. Proceed will open VQ in idle mode, displaying a ready-to-use window.

Figure 1
Figure 1:  Run, open and proceed are the three options
given when the application is opened.

VQ opens in a "run summary" window, which features real-time status monitoring for the threads in the program. This features a toolbar which allows the user to clear all the phases of execution that are not of interest, so only certain aspects of the program can be concentrated on. Data recording can also be controlled automatically from within the application by using an API function that embeds into the code of the program. Data recording tools allow the user to pause and resume the data recording, clear data or take a snapshot.

Most applications feature so many paths, it boggles the mind. How is it possible to focus only on what's important and ignore what's not?

VQ features a "call graph" which maps out the application as it runs. A linear graph then displays the 20 most demanding functions of the program. Thinner lines between functions indicate quicker paths, whereas thicker lines indicate slower or more expensive paths. This allows the user to immediately pinpoint where the problems may lie.

Highlighting can isolate a particularly suspicious function. After a function has been highlighted, there are two ways of focusing on it:

  • Filtering commands: This allows the user to hide functions or delete them. By hiding them, the call time to their callers is rolled up. Delete discards them completely.
  • Subtree commands: Let's suppose a function is showing as particularly expensive. By right clicking on this function, it is isolated and a menu opens. Clicking on "focus on subtree" will then adjust the dataset so it will display only the troubled function and all its descendants. By clicking on "expand top 20 descendants," only the subtrees of the slow, expensive functions remain visible. Once again, thicker lines, allowing immediate identification of the problem area, highlight the slower paths. This feature includes a series of expand and collapse commands that work within the subtrees. Clicking the expand and collapse functions will only effect the call graph display, not change the contents of the dataset. VQ also has an undo feature, so you can go back to any previous data configuration.

Clicking on the "function list" tool changes the output from a graph to a table, which displays numerical data.

These are just a few of the problems VQ can locate:

  • Unnecessary computation: VQ can point out when lists are sorted, even though the user has made no request to have the list displayed. An option would then be given to delete the sort function.
  • Redundant computation: If a value has been computed twice, VQ can point out that it is more efficient to cache the results the first time.
  • Redundant service requests: VQ displays the advantage of a few large operating system requests over many small ones.
  • Unnecessary waiting for services to complete: It may be possible for a function to continue on, rather than wait for a particular service to complete.
It is also possible to fine tune VQ's depth and speed of data collection. When an application is analyzed, data is instrumented. A copy is made and then VQ inserts data collection instructions. When the program runs, these instructions collect data at a preset level. VQ has three levels of instrumentation:
  1. Line: (Default) This setting provides the most in-depth and detailed performance data. VQ counts how often each line executes during a run, then computes data based on the number of cycles needed for one execution. This is the most demanding and time consuming setting.
  2. Function: This setting provides the same accuracy as line level, but with less detail.
  3. Time: VQ starts and stops a timer when each function begins and ends. This setting is accurate for the current run, but is influenced by microprocessor state and memory effects. This is the least taxing of the settings.

Not only can VQ find performance problems, it can simulate the performance of an application once the troubled function is changed. VQ will discard the unnecessary subtree from the dataset and recompute the remaining data, showing performance without the subtree. This new version can be saved as a VQ data file.

Figure 2
Figure 2:  VQ can compare the performance of the
original beside the re-engineered application

Clicking on the delta button (opens a "compare runs" function. This opens the Diff Call Graph, which allows the original application to be run side by side with the re-engineered one, comparing the efficiency of the two. New paths that show performance improvement are highlighted in green. If necessary, execution time for runs can be merged into one by using the epsilon button.

VQ doesn't stop short at analyzing only your data. It provides data for all the components in your program, including Windows DLLs and Microsoft Foundation Classes (MFC). ActiveX controls under Internet Explorer and Microsoft Office plug-ins such as Excel and Word are also covered.

When it comes to identifying and correcting performance bottlenecks on finished applications, Visual Quantify is one of the most useful and clever tools we've ever seen. That's where both its strength and its weakness lie. What if it is necessary to detect problems during the building process? VQ does not have the ability to identify and correct bottlenecks during the programming phase, only after the initial programming is complete. What about other problems beside bottlenecks? Again, VQ falls short, as it is useful only on problems of bottlenecking.

On Jan. 8, during a press conference in Las Vegas, Rational Software announced the extension of the profiling capabilities of Visual Quantify 4.0 to Visual Basic and Windows CE-based applications. This means that the same attributes of VQ are now available to those who work in these environments as well. This undoubtedly will dramatically enhance the marketability of this product as these are two of the more prominent programming tools on the market today.

Visual Quantify isn't going to be a magic cure-all to all of your programming woes. After all, it isn't going to write all of the code for you; it will just help you through some of the bottlenecking rough spots. It is, however a powerful and useful tool in the ongoing struggle to develop fast, clean, and efficient applications in today's highly competitive environment. With the use of VQ, and other tools like it, we will see a dramatic rise in the speed and efficiency of available applications. If you're using Java, C++, Visual Basic, or Windows CE, we think you might want to give it a try.

About the Author
Edward Zebrowski is a technical writer based in the Orlando, FL area. Ed runs his own Web development company, ZebraWeb, and can be reached on the net at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.