Java VisualVM giving bizarre results for CPU profiling - Has anyone else run into this?

Question

I have written this small (and brutally inefficient) class and wanted to profile it using the Java VisualVM.

public class Test {

    public static void main         


        

Answer 1

I don't think that's inconceivable at all. You have an application where the "payload" is fairly minuscule (though that of course depends on the value of n), and you have to accept that the extra effort required (to connect the profiler and shift all the information across to it) will swamp that payload.

This is not the sort of application I would be profiling in the first place since it's pretty obvious that the vast amount of time would be spent in fib anyway (for non-trivial values of n), marking that as an obvious target for optimisation.

I would be more inclined to use the profiler for more substantial applications where:

• it's not obvious where the optimisation effort should go; and
• there is some substantial amount of work to do in the payload.

If you really want to test that code, you probably need to bump up its effect by (for example) replacing:

int fib = fib(n);

with:

for (int i = 0; i < 100000; i++) {
    int fib = fib(n);
)

---

I'll tell you one thing to watch out for though. I don't know the internals of any particular JVM but using a recursive method where the reduction of the argument is slow is usually a bad idea, one that leads to stack space being exhausted pretty quickly.

By that, I mean a binary search is a good candidate since it removes half the remaining search space with each recursion level (so that a search space of a billion items is only 30 levels).

On the other hand, using recursion for a Fibonacci sequence on the number 1,000,000,000 would take about a billion levels and most stacks would have a hard time containing that.

Tail end recursion optimisation may avoid that problem but you need to be careful in case that optimisation isn't done.