Does filtering classes for cpu profiling work in Java VisualVM?

I want to filter what classes are being cpu-profiled in Java VisualVm (Version 1.7.0 b110325). For this, I tried under Profiler -> Settings -> CPU-Settings to set "Profile only classes" to my package under test, which had no effect. Then I tried to get rid of all java.* and sun.* classes by setting them in "Do not profile classes", which had no effect either.

Is this simply a bug? Or am I missing something? Is there a workaround? I mean other than:

• paying for a better profiler
• doing sampling by hand (see One could use a profiler, but why not just halt the program?)开发者_StackOverflow社区
• switch to the Call Tree view, which is no good since only the Profiler view gives me the percentages of consumed CPU per method.

I want to do this mainly to get halfway correct percentages of consumed CPU per method. For this, I need to get rid of the annoying measurements, e.g. for sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() (around 70%). Many users seem to have this problem, see e.g.

• Java VisualVM giving bizarre results for CPU profiling - Has anyone else run into this?
• rmi.transport.tcp.tcptransport Connectionhandler consumes much CPU
• Can't see my own application methods in Java VisualVM.

---

The reason you see sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() in the profile is that you left the option Profile new Runnables selected.

Also, if you took a snapshot of your profiling session you would be able to see the whole callstack for any hotspot method - this way you could navigate from the run() method down to your own application logic methods, filtering out the noise generated by the Profile new Runnables option.

---

OK, since your goal is to make the code run as fast as possible, let me suggest how to do it. I'm no expert on VisualVM, but I can tell you what works. (Only a few profilers actually tell you what you need to know, which is - which lines of your code are on the stack a healthy fraction of wall-clock time.)

The only measuring I ever bother with is some stopwatch on the overall time, or alternatively, if the code has something like a framerate, the number of frames per second. I don't need any sort of further precision breakdown, because it's at best a remote clue to what's wasting time (and more often totally irrelevant), when there's a very direct way to locate it.

If you don't want to do random-pausing, that's up to you, but it's proven to work, and here's an example of a 43x speedup.

Basically, the idea is you get a (small, like 10) number of stack samples, taken at random wall-clock times. Each sample consists (obviously) of a list of call sites, and possibly a non-call site at the end. (If the sample is during I/O or sleep, it will end in the system call, which is just fine. That's what you want to know.)

If there is a way to speed up your code (and there almost certainly is), you will see it as a line of code that appears on at least one of the stack samples. The probability it will appear on any one sample is exactly the same as the fraction of time it uses. So if there's a call site or other line of code using a healthy fraction of time, and you can avoid executing it, the overall time will decrease by that fraction.

I don't know every profiler, but one I know that can tell you that is Zoom. Others may be able to do it. They may be more spiffy, but they don't work any quicker or better than the manual method when your purpose is to maximize performance.