Search code examples
javamultithreadingperformanceprofilingnetbeans-platform

Selector, polling, Netbeans Platform Application and performance profiling interpretation

I've been trying to get a slow NBM Application to perform better. Upon running a profiler, I saw that most of the time is spent in poll0().

enter image description here

The top 6 methods (by Total Time(CPU) above are all in sun.nio.ch.WindowSelectorImpl or SelectorImpl.

Could someone help me interpret the profiling results? My guess would be that there are far too many threads repainting far too often. Could this be a plausible explanation?

I think I should add that the application is poorly programmed, with incompetent concurrency stuff going on. So, it's quite possible that there are stupid things going on.

Also, I'd be nice if someone could point out any reading material on how to find bottlenecks in such applications.

Solution

  • You ask for reading material on how to find bottlenecks in such applications.

    There is a contrarian view about how to find bottlenecks, which is explained here. The math behind it is explained here.

    The profiler you are using is not giving you useful information, because (pardon the military metaphor):

    • "Self Time" is not useful. It does not tell you who invokes the routine. You cannot expect all the blame to fall on the private, when everybody in the chain of command is the reason for her being there.

    • "Total Time" is not much better. It tells you the corporal and lieutenant were responsible, but it doesn't tell you for what, or how.

    • "CPU Time" is not useful unless you know there is no I/O or other system waits. If the army spends all its time waiting for reinforcements to arrive, don't you need to know why?

    • Some profilers give you a "call graph", but this post shows how easy it is for problems to escape from one of those. If you're a general, you have to defeat all of the opponents, not just some of them.

    • What profilers do is measure stuff. If the battle's taking 10 or 100 times as long as you think it should, what's the point of measuring? All you have to do is walk out to the battlefield, take a look, and see the problem. The chance that you won't see it is pretty small.

    Back to programming, what I suggest is getting a simultaneous stack trace of all the threads. You can quickly see which ones are actually doing something (not idling), and you can see what they are doing, and why. Guaranteed, you will see at least one of them doing whatever it is you're waiting for. If you want rough time estimates, take several such thread dumps.