Sun to add JFluid profiling tool to Java Studio

According to Infoworld,

JFluid is a "profiling" tool, software that examines Java applications and informs developers of potential performance bottlenecks in their code. It was developed by a team lead by Misha Dmitriev, who was transferred from Sun Labs to the software group last week, according to a statement on Sun's Web site.

Which makes me wonder about performance tools in IDEs. On the one hand, performance can be an important factor in software development, and educating programmers about performance isn't such a bad idea. On the other hand, performance considerations are often abused ('the root of all evil,' and all that).

So what kind of performance tools do we really want inside our IDEs? How is the answer effected by the type of programming language language considered? How about IDEs targeting students (DrScheme etc.)?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Preventing misguided optimization

I think that having a profiler on hand is more likely to prevent the abuse of performance considerations than to cause such abuse. Premature optimization is the root of all evil because it's usually misguided optimization — putting time and energy into fixing a non-bottleneck. A profiler is the best defense against misguided optimization; it might even help with the "premature" part too, if programmers realize "Hmm, a profile wouldn't show anything meaningful yet, since only part of the code is done."

That last part may be too optimistic, though. Despite all I supposedly know about the evils of premature optimization, I still catch myself doing it disturbingly often.


I agree that profiling is important, and can help against premature optimization.

But what about the danger of premature profiling? ;-)

Student profiler

I think it would be useful to have a profiler in ide's for students. However, it would need to be able to do things like show how the profile changed as input size changed.

I have seen some interesting code from new programmers. For example, on piece of code was applying a function on a linked list to each element. But, instead of applying the function, and then following the next pointer, the student used a for loop with a counter, so they had turned a O(n) function into an O(n**2). Another was using string functions to get an absolute value of a number. A good profiler would help find these problems.

Useful Profiling

Premature performance profiling is generally counterproductive. Memory profiling, OTOH, is useful throughout the development life cycle. Being able to see how objects accumulate and interconnect provides more information about the correctness of an algorithm.

As a bonus, on modern platforms, memory usage is often the single greatest driver of performance. Although issues like locality are not manageable by the Java programmer, excessive creation of temporaries and unneccessary stress on the GC are within her control.

...just a few thoughts from a former dev lead for JProbe Profiler, JProbe Threadalyzer, and JProbe Memory Debugger...

Profiling and cost model

The problem I have with not doing pre-mature optimization is that I don't always know the proper timing for it. Should I wait until I have built the desired functionality and then profile it and address performance issues which may not show up in the profiler as a hotspot? What about design decisions that affect performance systemically? What about the impact of profiling and the skewed results?

I think profiling is a very useful technique but there are applications where a priori knowledge of the "cost model" of your critical operations is necessary to avoid expensive redesign(and grafting performance later on). I find profiling generally useful for code tuning but the cost model approach will help prevent expensive work later on.

I was turned on to this aspect of performance by this article: "J. L. Bentley and B. W. Kernighan and C. J. Van Wyk, An Elementary C Cost Model, Unix Review, Vol. 9, 2, pp. 38--48, February 1991". Unfortunately, I don't have access to this article anymore. Highly recommended reading to the practitioners of high performance systems.