Gregg Sporar's Blog

Ja, Jazoon

I attended the first three days of the first ever Jazoon conference. There were some rough edges, which is understable since this is their first year, but all in all it was okay. One of the best things about it was the venue: a movie theatre. I've always heard people talk about how great it is that JavaPolis is in a movie theatre and now I know why. There are two big advantages: the projected image on the screen is HUGE so everyone can see what the presenter is talking about and the chairs are soooooo nice and comfy.

As always, of course, the best part of these conferences is the people you talk to. As I mentioned in my entry about NetBeans Day Zurich, it was a great pleasure to meet Fabrizio Giudici. One of the presentations I did at Jazoon was on the NetBeans Profiler. It was essentially a slightly slimmed-down version of the JavaOne session that I did with Jiří Sedláček and Jaroslav Bachorík. Fabrizio was nice enough to write a blog entry about it.

William Louth posted a comment to Fabrizio's entry that started with: "Integration within an IDE is overrated and it is certainly not the fastest way to solve real world performance problems...." In his second paragraph he went on to state that "... the integration of the NetBeans Profiler, which by the way is a nice low level code profiling tool, into an IDE is only useful for unit (code blocks) profiling and not for application profiling unless we are talking about a desktop application."

I have a tremendous respect for William and would happily concede that he knows more about performance tuning and troubleshooting than I do (particularly on enterprise applications). And he seems like a nice enough guy - I chatted with him briefly after his session at TheServerSide Java Symposium in Las Vegas back in March. But I am not in complete agreement with his comments.

William is focusing on test and production environments and interestingly, I state in the presentation that one of the goals of integrating the profiler into the NetBeans IDE is to help developers find and fix performance problems before an application is moved into production. So I think William and I are in agreement there - this is a tool primarily for use in a development environment.

Further, the only production JDK you can attach the NetBeans profiler to on-the-fly without restarting the JVM is JDK 6, and not many folks are running JDK 6 in production yet. So I fully recognize the profiler's limitations there - it is much easier to stop and restart desktop applications than it is to do that with web/enterprise applications that have users connected! I would also agree with William's follow-up comment (in response to Wade Chandler's comment) that premature code optimization is not in anyone's interest. And finally, since the profiler is just looking at what is going on inside a single JVM, there is much information (particularly for an enterprise application) that it just cannot see.

I think there are two areas where I disagree with William. First, as he pointed out the profiler is "useful for unit (code block) profiling," which means to me that the benefits of having the profiling tools integrated is not overrated. In other words, to profile a block of my code what better way is there than to have my profiler integrated in so well that from within the editor I can simply pick a context menu entry and I'm all set. Further, with the NetBeans 6 profiler it is even easier to define blocks of code for profiling now that the profiling points feature has been added.

Second, I have worked on a non-trivial production web application where the memory profiling feature of the NetBeans profiler was invaluable. Memory leaks can quickly become performance issues. Admittedly, I was not allowed to connect to the production server (again, because of that whole restart issue), but the sysadmin set up a test box for me, gave me a duplicated environment and the appropriate load tests and I was able to find the problem after others had tried repeatedly with different tools. Admittedly, the integration of the profiling tools into an IDE was not what ended up making the main difference in this case - but integration certainly does not hurt. :-) Would that particular problem have been found more quickly with a tool from JInspired? I honestly do not know - but I tend to doubt it.

In the end, it boils down to the standard advice: pick the right tool for the job. While you are doing development, an integrated profiling tool can make a difference. After your application moves into production then things get more complicated. The NetBeans profiler might be able to help, but it depends upon the type of application and the type of problem that is occurring.

Comments

• Integration may not be crucial for everyone, but we already did a lot of profiling work with the new integrated version in NetBeans6 and found very easily some memory and CPU consumption issues, which would have been much more difficult without such an integration.
  The main thing is that we do not have to setup more tools so that we can use them with our codebase, so the additional overhead for doing a profiling run is small.
  This enables us to do a quick profiling session, if anything comes up.

  We really appreciate the work done on integration. Everybody should try heapwalking during debugging!

  Posted by: sven on June 28, 2007 at 01:44 PM

• Hi Gregg,

  I do really like the NetBeans profiler. I have used it myself when writing our JXInsight Probes runtime. The NetBeans profiler was instrumental (pardon the pun) in helping me deliver a probes runtime that significantly out performs any other resource metering framework of similar feature set. When I need to do low level profiling of our own code (unit code) I tend to reach for NetBeans Profiler if I cannot readily use the Probes itself. It is the only profiler that I have found sufficiently reliable and accurate at least in my testing. Though to be honest at this stage in my career I can nearly profile code just by looking at it.
  I do like the ability to set code profiling points within the IDE (a really nice feature) but again I worry that enterprise developers will not see the forest (model=paths, flows,...) for the trees (code).

  I should point out that I am an IntelliJ user and though NetBeans is looking more and more attractive with each release (nice UI) I would have liked for the NetBeans profiler to have remained somewhat independent of the IDE especially since it would appear that we are moving more and more away from the memory profilers having to be attached directly to the JVM (offline dump file analysis). This explains part of my gripe and the rest is because I am focused more in the later stages of the application life cycle which you have also noted.

  The next time you have a critical performance problem at a customer site then give me a shout. I will bring my tool and you can bring yours. I am more than confident that a distributed contextual performance monitoring solution like JXInsight will solve much harder (and larger) problems in a shorter time than a code profiler - unless of course we are talking about a memory leak and not necessarily a memory capacity problem.

  Regards,
  William

  Posted by: wlouth on June 28, 2007 at 01:46 PM

• Hi William -
  >I would have liked for the NetBeans profiler to have remained somewhat independent of the IDE
  Take a look at this. Note what it says on slide 7. :-) You might want to keep an eye on Mandy Chung's blog as that project continues to develop.
  >a distributed contextual performance monitoring solution like JXInsight will solve much harder (and larger) problems in a shorter time than a code profiler
  Agreed. Especially if someone with your talent is at the controls.
  >unless of course we are talking about a memory leak and not necessarily a memory capacity problem
  Agreed again. Gee, maybe there's not that much that we disagree about after all.... :-)
  

  Posted by: gsporar on June 28, 2007 at 02:02 PM

• Jazoon was great ! and the NetBeans profiler is the best on town...

  Posted by: felipegaucho on June 30, 2007 at 03:33 AM

This work is licensed under a Creative Commons License.