Get Started Profiling Applications in Eclipse

Why Profile?

Application profiling is one of the most valuable techniques available for programmers to get out of the world of premature optimization, and back into reality. By simply profiling an application, it becomes immediately apparent where the overwhelming memory and CPU burdens are, and allows you to quickly squash them.

Romain Guy recently blogged about his use of the Netbeans profiler as it is a very powerful and well implemented tool; the significance of this comes from the fact that Romain is an Eclipse user, but he is using Netbeans because Eclipse's profiling support left him wanting. While I can't make any promises about beating the overall implementation of the Netbeans profiler tool, I can show how to get started with Eclipse's up and coming Test and Performance Tools Platform . The Eclipse Test and Performance Tools Platform (or Eclipse TPTP for you acronym nuts) is an infrastructure for doing all kinds of monitoring and testing of applications from within Eclipse. It just so happens that it ships with views and editors for analyzing the recorded performance data.

The World Beyond These Walls

Before I go to far, I should mention that there are two community-provided Eclipse profiler alternatives available (that I know of) -The Eclipse Profiler , and jMechanic . Neither of these in their current state work with 3.1, although the Eclipse Profiler has supposedly been patched into 3.1 Eclipse submission here .

The reason I am not giving any information about those two plug-ins, aside from their 3.1 compatibility, is that Eclipse TPTP is an Eclipse Foundation project, and as such will carry with it the direction and motivation of profiling and monitoring on Eclipse as time goes on. Besides, this project is subject to the same aggressive development that we've come to expect from Eclipse projects. Note, for you history buffs, Eclipse TPTP used to be known as Hyades.

In addition, there are of course many other Java profiling software suites for use outside of Eclipse, including JProfiler , YourKit Java Profiler . and let's not forget to mention the Netbeans Profiler - note that some of these cost cold, hard, cash.

Finally, I even described the groundwork details for implementing your own profiler if you are crazy enough in these tips here andhere .

Let's Get Started

Ok, so you're still here. That must mean you're interested in profiling Java applications in Eclipse with TPTP. Most of the 'Overview' documents I've found for TPTP first start by describing the architecture. While I think understanding the architecture is important, I don't think it helps initial adopter enthusiasm any; so, I won't go in to too much detail. What I will say is that the profiling tools in TPTP are broken into two key parts - the JVM being profiled, and the agent collecting the profiling data. This is important because the JVM being profiled doesn't have to be code specifically embedded in your Eclipse installation (such as in a project). It can be in an external JAR file, or even in a seperate JVM on another computer (such as a test web server!).

What to Download

To cover the common use cases of the TPTP profiling tools, you need to download two things (both from the Eclipse TPTP download page :

• The TPTP Runtime - This is the plug-in suite that you install into Eclipse to get all the nice views and editors for working with profiling data and connecting to an active agent.
• The Agent Controller - This is the platform binary that runs as a separate process, and whose sole job is to act as an intermediary between the JVM being profiled and the TPTP plugins you've installed in Eclipse. Note that the provided agent controller that is currently the 'released' version is a somewhat out-of-date implementation that is scheduled to be replaced in the future. I'll be describing how to use the released version as it has a more formalized process at this point. Feel free to get the technology preview, but realize that it will move off in a different direction from this tutorial.

Installing and Configuring

Once you have them downloaded, you have to take a few quick steps to get them configured for use. Let's start with the TPTP runtime, as installing it is easy and familiar for most Eclipse users. To install the TPTP runtime, simply unzip the downloaded ZIP File over your Eclipse installation. I believe it is rooted with a 'eclipse' folder inside since it has features and plugins inside of it, so you would tell your zip program to unzip it directly over Eclipse. Alternatively, you could put it in a custom extension location, as I describe in this tip: Manage Multiple Eclipse Installations (Note that this is how mine is installed).

Next, to install the agent controller, you must first unzip the agent controller into its own directory.

Note : I'm a Windows user, so these instructions will be windows-centric. I apologize for those of you that aren't. Note that the agent controller should come with a readme that, when compared with this, should give you some idea of the steps that were missed.

Once you have the agent controller unzipped to a directory, you have to take a few quick steps to ensure that it is configured for your environment:

1. Run the SetConfig.bat Configuration Wizard - This script, located in [AGENT CONTROLLER INSTALL DIR]\bin will ask a few quick questions. The first question will be which Java installation the server should use. Assuming that checks out OK, you should simply be able to press ENTER through all the questions you are asked (which will simply select the default values), and then the script will create your configuration files.
2. Add The Agent Controller 'bin' directory to your PATH environment variable - This is fairly simple - in the case of Windows XP - just go to Start->Control Panel->System->Advanced [Tab]->Environment Variables [Button] and add the path to the agent controller installation directory to the end of the PATH system variable.
3. Add the RASERVER_HOME Environment Variable - ON the same 'Environment Variables' dialog as described above, add a new system variable with the name RASERVER_HOME and type in the full path to the agent controller installation directory as the value.

Note that the 'Getting Started' document that is included in the Agent Controller distribution describes this process in more detail, and also describes the steps involved to install the agent controller as a Windows Service - this can be valuable as whenever you want to do any profiling, the agent controller has to be running, or you will be shown an error.

Now you are ready to try and profile an application.

Using TPTP

TPTP is fairly simple to use as long as you understand the different forms of monitoring that it offers. There are essentially three categories of monitoring currently available (as of the 4.0 release):

• Memory/Object Allocation Analysis - This form of monitoring determines how many objects of a specific type have been allocated, how many are active, how much memory those objects take up, etc. As you can guess, this is a particularly useful tool for optimizing memory footprint of an application.
• Execution Time Analysis - This form of monitoring analyzes how much time individual method calls take to complete, and can show the execution history of an application. As you can guess, this is a particularly useful tool for optimizing execution hotspots.
• Code Coverage : This form of monitoring shows the areas of the application codebase that are invoked the most often, and shows percentages representing how much of the code base was used, and with what frequency. This is an interesting tool for getting a high-level idea of the highest trafficked areas of the application given an average usage scenario.

Once you have Eclipse started, you should see a new launch configuration button available on the toolbar:

This is where you will start an application for profiling. To start, I have a project in my workspace, and I have created a class in it with this format:

package com.javalobby.tnt.profile;
 
public class ProfileTest {
 
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		StringBuffer b = new StringBuffer();
		for(int i=0; i<1000; i++) {
			b.append("Blah blah blah");
		}
 
	}
 
}

I then right click on the class in the navigator, and press the 'Profile...' menu item under the 'Profile As...' context menu. Then I create a new launch configuration for this class:

Next, we have to tell Eclipse what we want to have profiled, and to what extent. Let's start with execution time, as that's often the most interesting. Go to the 'Profiling' tab, and select the 'Execution History - Full Graphical Detail' profiler set. Then, press the 'Edit...' button to the right. Go to the 2nd page of the wizard by clicking 'Next', and then you will be presented with a page that looks like this:

For now, simply leave everything as default. Go to the next page of the wizard, which should look like this:

On this page, make sure that the 'Default' filter set is selected. Now hit Finish.

Now we are ready to run the profiling, so let's start the program by clicking 'Profile'.

Oops, did you get this error?

If so, it's because the agent controller wasn't running. Start it by running '[AGENT CONTROLLER INSTALL DIR]\bin\RAServer.exe'. If you followed the directions above, you should simply be able to run this by going to Start->Run->'RAServer' [Press Run] .

Now when we run the profile we should see be prompted to switch to the profiling perspective:

...at which point we will see something like this:

This is a profiling session - as you can see, the only type of analysis available to us at this point is 'Execution Time Analysis'. That's because that is the only form of profiling we selected in our launch configuration. If you double click on Execution Time Analysis node, you will be presented with the 'Execution Statistics' view:

This view gives you an overview of the various methods that were invoked, and how much time they took overall based on their number of invocations. In this particular case we can easily tell the culprit of the largest consumption of time was the main method calling string buffer append, but, let's pretend for a moment that the program was a little bigger, and a little scarier. In that case, seeing that StringBuffer.append was the heaviest used method won't always help us, because we don't have context.

So, instead, let's try a different view. This time, right click on the 'Execution Time Analysis' node, and select Open With->Execution Flow.

Now we are presented with a split screen editor. The top half shows a graphical representation of where the most time was spent (the longer the bar, the more time spent in that method). The bottom half shows the same information in a more traditional tree-table style format. At this point we can easily see that the main method is the one responsible for invoking append 8 jillion times:

Now, your experience may vary. Try playing around with the graphical section for a while; I had to zoom in to get this segment to be visible. You can get down to exact method detail if you zoom in enough:

Ok, so clearly, the tree on this page tells us that the main method is the burden, and if we scroll enough, we can learn that the append method is the main culprit. If we double click on the append method on that tree (or double click it back on the statistics page), however, we can learn a little bit more. Once double clicked, we are presented with this information set:

As we can see, even without leaving the statistics page, we can get a pretty good idea of going on with the help of this page.

Going Back

Ok, a little bit about what we skipped over before. On the profiling tab for our launch configuration, I skipped over the execution time analysis page, and the filter sets page. Let's talk about those a bit.

Filter Sets

Filter sets are global to all of the analysis tools, and effectively block off certain parts of the classpath (such as the core Java classes) so that they aren't profiled. Why would you want to do this? Well, two reasons. One, profiling a bunch of classes you don't own can give you information overload; in the overwhelming majority of cases, you want to know where *your* code is slow first; and it turns out with boundry classes (which we'll learn about in a minute) you can figure out what calls into core Java are causing the problem, without profiling the whole ball of wax. Two, profiling the entire core Java libraries along with your code will have a *very* negative impact on performance. These profiling tools are very efficient, but profiling the entire JDK is a huge task. With no filter on, you will probably not want to wait for your application to start. Filtering ensures that only the classes you want to profile are profiled, and then if you need to dig deeper, you can tweak the filter to include certain classes or packages if needed.

Boundry Classes

When configuring time analysis, one of the options available (as seen on the 2nd page of the wizard) is to include boundry classes outside the filter set. I mentioned this briefly above, but effectively this just means that, given the example above even though I have filtered 'java.lang', we still get the StringBuffer.append method because it's a boundry class to our code.

So, What's Next?

Well, things left for you to explore include:

• Memory Analysis Tools
• Code Coverage Tools
• Profiling External Jars (Hint, check out the tutorial documentation in the Eclipse help)
• Statistical Analysis - There is a whole suite of graphs and diagrams available that I haven't yet shown (Stolen from the TPTP documentation): 
  

I hope this gives you a head start on the up and coming Eclipse Test and Performance Tools Platform.

출처: http://www.eclipsezone.com/eclipse/forums/t52038.html