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:

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/