Profiling, part 2

Last week's entry prompted Joseph Ottinger to ask the question: “how much should any given developer profile?”

The resulting discussion over on TheServerSide made for interesting reading.

The discussion highlighted something that I neglected to mention in last week's entry: there is more than one type of profiling. The different JVM profilers that are available can only show you what is going on within a JVM. They are not going to provide detailed information about which tables in your relational database need more indices. Nor will they help you prove that the bottleneck on an e-commerce application is inadequate SSL accelerator performance.

But for a Java developer, a JVM profiler can make a big difference. When performance within the JVM slows to a stop (and I have seen that happen) you no longer have a performance problem, you have a bug to fix. So to me it is a responsibility issue. As the developer of a piece of code I should take ownership for how it performs. That ranges all the way from memory usage to things like how much time a Swing application spends in the Event Dispatch Thread.

With the integration of a profiler into NetBeans profiling is easily added to the edit-compile-debug-test cycle to become part of how a developer meets the responsibility of producing quality code.