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
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
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.