JProfiler: Your Java Code Could be Running Faster in Under Two Hours
A couple of weeks ago I found myself in a position which is well known to any professional Java developer: my software was simply too slow. After tackling some obvious pain-points, I had to turn to help of a profiler. At the end of the day, I managed to cut the execution time of some processes by 50% and more, by using JProfiler form ej-technologies.
The Open Source Alternatives
As an Eclipse user and a strong OSS supporter, I first started searching for the open source alternatives. In the past, I have used the Eclipse Test & Performance Tools Platform, aka TPTP. However, TPTP is no longer an option for me since it does not support Mac OS X. TPTP is a good, solid, tool but it is not a simple one to install and use. Just to be clear: a simple tool would be a tool I can install and use without reading a manual. TPTP comes with a complex setup process.
I searched for some other free tools. I found this list of open source Java profilers and wasted about 3-4 hours running through it. None of them worked well. Most of them were buggy, some eventually worked but did not produce enough information or produced too much information, which is just as bad. Most of the tools are focused on memory analysis, while I needed execution time analysis. I had to look elsewhere.
My Experience with JProfiler
I'll start from the bottom line. JProfiler is not the prettiest tool you can find. Its' integration with Eclipse leaves much to be desired. However, it has many advantages:
- Very simple to use, compared to tools in its' class.
- Provides all the information you will desire with extensive views and predefined filters to make sure you'll get just the information you need.
- Relatively low execution overhead with many profiling options (instrumentation, sampling, etc.) and highly configurable settings.
- It displays the information while the program is running, as opposed to other tools I've used, where you have to stop the analysis to get some results.
I downloaded JProfiler and installed it using the provided installer. Like other profilers, JProfiler integrates with the IDE, supporting Eclipse and IntelliJ. In Eclipse, you use the "Profile" command, which uses the same "Launch Configurations" as the "Run" and "Debug" commands. At this point, you'll be transferred to JProfiler to start the profiling session. It took me less than half an hour to start profiling (including the download and installation), without any prior knowledge of the product and without reading any documentation. It took me another half an hour to explore all the views and understand where I can start cutting execution time. About half an hour later, I was running much faster. As I wrote earlier, about 50% faster with a couple more fixes I did that day.
Since then, I had a chance to use JProfiler on a number of occasions and it just works: profile, find the problem, fix and retest. I don't need any special preparation or setup: I just launch JProfiler using my existing launch configuration and a couple of minutes later I have the results. I even tried it on Windows, as well and it works exactly the same. You don't need to buy an additional license for that: you can remotely profile your application across the supported platforms (Windows, Mac, Linux, Solaris, AIX and HP-UX) without running JProfiler on the remote machine.
JProfiler in Action
I'm not an expert user and my experience with JProfiler is limited. I took a few screenshots to show how simple yet powerful is JProfiler. The first screen is the Session Startup, which is the first dialog you get when you launch a new profiling session.
What I like most about this window is the two lower bars that give you an estimate on how intensive this profiling session is going to be in terms of memory and CPU usage. If you change any of the profiling parameters, these bars will reflect the change. Going into the profile settings, you get an assortment of configuration options:
You can choose from predefined settings or use a custom settings. Once you select an option you'll see some explanation in the dialog itself, so there's no need to start looking for documentation. Once you get the hang of it, you can start exploring the custom options, but I found the predefined settings totally sufficient for my needs.
My focus was on execution time of a simple Java program, so the default option worked best for me. When analyzing my execution time, the most helpful tool was the "Hot Spots" view:
In this view, the most expensive calls are sorted in a descending order. You can expand the call and see which methods invoked it and, for each of those methods, what was its' share in the overall performance cost. This graph is updated every 5 seconds while the program executes.
You may also choose to see it as a call graph:
In this graph, each method gets a color according to its' contribution to the overall performance. The more expensive the call, the darker it will be. For each method you can expand the callers and methods being invoked. This makes it a good tool for identifying the critical path. All of these views can be exported to a readable HTML format, including the graphs.
Summary
It is my opinion that every professional developer should know how to profile code. I don't believe profiling is an art which should be left to dedicated performance teams (my former employer took that approach), mostly because it is the combination of knowing the code and mastering the profiling technique which yields the best results. In an ideal situation, every developer should have a profiler in his or her arsenal, ready to be launched at any given time.
Should you buy a profiler? Even if TPTP works on your platform, it is still behind the commercial tools. It seems that profilers are one of the few segments in the development tools market, where open source tools are not catching up with their commercial counterparts. It is more of a question of how you value your time. You can read my related post of the subject from one year ago: When saving a buck actually costs you more. JProfiler will simply provide the results faster.
From http://zvikico.typepad.com/
He is a entrepreneur and a software architect from Tel Aviv, Israel. He is also a technology freak with about 20 years experience working with computers. He is currently working on his first private initiative in the area of software development tools. His vision is to maximize the abilities of software developers by providing pragmatic tools that enable them to get fast results. Zviki is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 20657 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)










Comments
Michael Bien replied on Wed, 2008/07/09 - 5:38am
(or https://visualvm.dev.java.net/ which has a subset of the NB profiler features and is now included in the JDK)
I have no JProfiler license so I can't compare them, but all I see from your entry would be possible with the NB profiler too - the UI even looks very similar.
christiaan_se replied on Wed, 2008/07/09 - 6:18am
You should definitely check out the Netbeans profiler. I normally use Eclipse, but I think this is the feature which makes Netbeans far better than Eclipse. I've tried TPTP, but somehow they completely missed the concept of being userfriendly and providing insightful information when it comes down to performance and memory analysis. It took me quite some effort simply to get it running. With netbeans you are up and running in a couple of minutes and you have all the information you need to do some good analysis (also have a look at their getting started tutorial, very well written). Before I used Netbeans profiler, I also tried JProfiler. Also a good tool indeed and similar to NB profiler. One thing I noticed is that NB profiler can also handle profiling of memory intensive applications (which is a likely application to profile;-) I believe this is because it is based on what they call JFluid technology. And it is open source of course.
Lzszlo replied on Wed, 2008/07/09 - 7:02am
Jess Holle replied on Wed, 2008/07/09 - 9:06am
I'd concur that the NetBeans profiler is quite nice -- for use cases where it holds up.
The CPU profiler has a few gaps, though:
Finally, the VisualVM version of the CPU profiler does not allow you to instrument only parts of your application and thus has issues with large applications.
The memory profiler in NB and VisualVM is more mature, but operates on a fairly detailed, low level. Higher level capabilities like those in Eclipse Memory Analyzer Tool (http://www.eclipse.org/mat/) would be a really nice addition. Ideally an IDE independent core would be split out of Eclipse Memory Analyzer Tool and re-used in both Eclipse and NetBeans...
Jess Holle replied on Wed, 2008/07/09 - 9:55am
in response to: jessh
I've since been informed that this shortcoming in VisualVM was addressed in Visual VM 1.0. I had not tested this since a pre-release version and didn't realize/notice this change.
Yaozong Zhu replied on Wed, 2008/07/09 - 10:54am
I tried JProfile once with the 10-day trial licence, but I couldn't be able to set it up for maven-based project. Neither was Netbean Profile. I wonder they are only working for Ant-based projects (build.xml) or not.
I totally agree with Zviki.
[quote]It is my opinion that every professional developer should know how to profile code. [/quote]
Zviki Cohen replied on Wed, 2008/07/09 - 11:36am
Does NetBean Profiler provide Eclipse integration? :-)
Seriously, you could say I'm an Eclipse fanboy, so I didn't look in that direction. I'm working on an Eclipse plug-in, so I will need to launch my application from Eclipse and profile it from NetBeans, which is probably feasable. Still, kind of unnatural, to say the least.
Thanks for the comments. I'll check it out.
Jess Holle replied on Wed, 2008/07/09 - 11:38am
Zviki Cohen replied on Wed, 2008/07/09 - 12:16pm
I see there's a lot of noise around VisualVM. I didn't test it, yet, probably it has one simple requirement: a Sun JVM. Which means it's not for Mac OS X users.
BTW, on OS X we have DTrace, with the provided Apple UI, which is called Instruments. Without a doubt, this is the best UI I've seen for a profiler. It shows most of the information you get from VisualVM. I'll do my best to review it in the near future.
Jess Holle replied on Wed, 2008/07/09 - 4:55pm
We have 2 Macs in our house...
That said, I don't touch them for Java as the platform's commitment to and support of Java have seemed quite shaky for quite some time. I noted a swing away from Mac OS X (and towards Linux, of course) at this years JavaOne that I would attribute directly to Apple's ambivalent (at best) attitude towards Java.
Milind Rao replied on Thu, 2008/07/10 - 12:23am
Jaroslav Bachorik replied on Thu, 2008/07/10 - 1:37am
in response to: zvikico
Jaroslav Bachorik replied on Thu, 2008/07/10 - 1:39am
in response to: os2baba
Did you try creating the applet in NetBeans and then invoking "Profile File" action on it? It will start the applet in profiling mode and off you go :)
Also, you can use dynamic attach (if running in JRE 6) to attach to an applet running inside a browser and profile it.
Dino replied on Thu, 2008/07/10 - 8:44pm
I spent about 1/2 hour with visualvm and the profiler doesn't work very well. Bunch of errors get generated and the server crashes. Have to wait a few more iterations before I try it out again.
Slava Imeshev replied on Fri, 2008/07/11 - 12:35am
in response to: mbien
I have been using JProfiler for over 5 years. Having had experience with other commercial and free tools, I can say that JProfiler takes the cake. If you are in business of delivering fast Java applications, JProfiler is a must-have tool.
Regards,
Slava Imeshev
Cacheonix: Fast Clustered Java Cache
Milind Rao replied on Fri, 2008/07/11 - 1:10am
in response to: yardus
Michael Bien replied on Fri, 2008/07/11 - 3:54am
in response to: os2baba
[quote=os2baba]It's such a pain in Netbeans to have to keep setting the "main" project and then selecting the class to run instead of just clicking on the run configuration dropdown menu. [/quote]
No, NetBeans has run configurations like any other mainstream IDE too. The only exception are applets whch you can't currently confugure explicitly, which is solved in 6.5. I use them quite often.
But yes you are right you are asked to choose the main project the first time you hit run and have to change it again whenever you want to run a different project.
Milind Rao replied on Fri, 2008/07/11 - 4:06am
in response to: mbien
Milind Rao replied on Fri, 2008/07/11 - 4:18am
in response to: os2baba
Michael Bien replied on Fri, 2008/07/11 - 4:35am
in response to: os2baba
Alessandro Borges replied on Wed, 2008/07/23 - 7:16am
JProfiller is a great tool.
Recent tools, like NetBeans Profilers, still lacks charts like call graph, memory walking, back trace.
This is really necessary when you need to discover persistent roots of ungarbaged data.
m. n. replied on Thu, 2008/07/24 - 5:27pm
To the maven/netbeans/profiler commenter:
Netbeans (so far) doesn't have great support for the profiler for maven projects. Basically, the classpath doesn't get set, esp irksome is multi-projects (more than one pom). This was the case in nb6.0, maybe something changed in a recent update, but I doubt it. Maybe nb6.5 changes something. Frankly, though, it's the integration between the nb mvn plugin & the nb platform that's the issue, not netbeans per se. (Try it: the profiler may *look* like it's working, but compare profiling an Ant app to a Maven app, & you'll see the difference)... To profile my maven app, I created (in unix, of course) a symlink tree of all my maven multi-project sources into a single "virtual" src dir (there shouldn't be overlaps in files, of course!), and calculated all my dependencies to an output file (mvn dependency:build-classpath -Dmdep.outputFile=mycp.txt ), and used that as my ant classpath. Quite a hack, but once it's done, it stays done (by re-running a shell script to update my symlinks).
-m
bphanirajkumar@... replied on Tue, 2009/07/21 - 4:29am