Lambda the Ultimate

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.

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

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.

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

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.