Java Programming: Profiling your code

Java Programming: Profiling your code

First of all, I'm really sorry for my absence during this month, but the free time I've been having I've been trying to stay away from the computer so I could rest. But I'm back and once again I'll write a bit about programming.

This time I want to write about profiling. First of all, what is a profiler? Here's a quote from wikipedia that explains it very well:

A profiler is a performance analysis tool that measures the behaviour of a program as it runs, particularly the frequency and duration of function calls. The output is a stream of recorded events (a trace) or a statistical summary of the events observed (a profile). Profilers use a wide variety of techniques to collect data, including hardware interrupts, code instrumentation, operating system hooks, and performance counters.

Profiling is something that isn't always done in projects. But if speed is crucial of someone bottlenecks are detected profiling during developing can be a real help to spot the problems. Profiling doesn't show how to solve the problem, it only spots the problem, it might be a slow method or usage of too many memory due to sloppy memory management. Sometimes such cases are difficult to spot, profilers make that task easier.

I've chosen to write about profiling because lately I've been doing profiling in various pieces of code in order to improve it's execution speed. Since I'm a JAVA developer I've had to use a java profiler, there are many profilers from where to choose although I've chosen a commercial solution, jprofiler. It's a bit pricey but the 10 days license really get you addicted to the tool.

At JProfiler's website they give you top 10 reasons for why choose jprofiler:

• Exceptional ease of use
• Real-time display of profiling data
• The unique heap walker
• The powerful CPU profiler
• The integrated thread profiler
• Excellent support for Java Enterprise Edition
• Extensive QA capabilities
• Broadest support for platforms, IDEs and application servers
• Low overhead
• Extensibility

The reasons presented seem reasonable to me although there's a little warning regarding one of the reasons I want to make. When it's being said that low overhead is a good reason to choose jprofilers. What is really being said is that jprofiler allows the user to record only the needed data, so when no data is being recorded at all the overhead of having jprofiler attached to the application isn't that big.. but if all the data collects are active, well that's another story.

To me, the best reasons to use Jprofiler are the various profiling views, the IDE integration, remote profiling - this includes JBoss and Tomcat attachment for profiling which for me is a great -, threads view and the CPU view.
The CPU is really handy and as you can see in the image on the left, that view gives detailed information, by thread, such as time spent, number of invocation and the time share. The navigation can then be done between threads and in depth to actually understand where the time is being spent, for me this is a really great and helpful feature.

Although if the thread state is what it needs to be analysed there is no problem at all. JProfiler as a thread view which is a detailed graph of the threads running and their state, if they're running, blocked, waiting or using network I/O.

In the end the only big problem that is found is the license price, which goes from 179 euros for an academic license to 409 euros for a standard one, even with volume discounts the licenses price is still a bit expensive.

It still a great tool and anyone that needs to profile their java applications should try it, at least for the 10 free evaluation days.