This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Today if I double-click the node, it only opens the current node (unless it has only one child, in which case that will also be opened.) This requires the user to click a whole bunch of times to get to the interesting part. Often, there's a significant number of methods where one child dominates the most of the running time. NB profiler should open all those "dominating" nodes so that people can get to interesting portions with less clicks. This feature can be seen in many other profilers, such as YJP.
Are you able to list 3 other profilers with this behavior to demonstrate "many others"? Whereas for nodes with just one child it's clear what should be expanded, I think that any kind of heuristics or automatic decisions what's important for the user would be dangerous. The treetable with results is just a browser - tool for the user, not automatic problem detector. I can imagine that the user chooses the right subtree as the one with longest time, but then he just checks what the distribution of time among methods is. Typically if there is a method taking 80% of time, it's IO or something similar which always takes a lot of time and cannot be improved much. But providing a way to assist the user with finding hotspots is interesting and useful idea. You create a RFE (issue of type ENHANCEMENT) and describe all your ideas about it there.
Sorry - should be "you can create a new RFE..." :o)
Your Kit Java Profiler does this, so does Borland OptimizeIt. Those are two other profilers that I have experience with, and they all behave this way. "many" might have been a poor choice of the word, but I think I still get the point across that this is a feature commonly seen, and certainly so for all the other profilers that I've used in the past. The point I'd like to stress is that this is not so much about guiding the user to the hotspot. Instead, it is about not forcing me to mindlessly click the mouse dozen times. Finally, I disagree with "Typically if there is a method taking 80% of time, it's IO or something similar." I'll attach another screenshot, but in it you can see that there's 10 or so nodes at the beginning of the call stack where simply one child dominates all the others. This is the kind of expansion I'd like the tool to do for me. Reopening the issue in the hope of having you reconsider this, but of course it's eventually up to you to decide whether you like it or not...
Created attachment 35896 [details] Imagine the number of clicks you have to do just to get here
Thanks for the screenshot and for the example. I understand that in this case expanding first 10 items is what the user most likely wants. But what is the threshold from which "user definitely" wants to go this way? And what happens if there is no major node? What am I trying to say is that we cannot make such decision exactly instead of the user and there shouldn't be such inconsistency when sometimes the tree expands automatically and sometimes not - the user won't understand the reason why and won't see/change the threshold. Also, I can't see the "minor" skipped nodes in your screenshot - they might be not important for you in your example but they can be very important for other user in other application. This way we would skip them, forcing the user to focus on other data that we think are more important. So the default behavior should stay as it is right now - table with results is just a Swing component allowing the user to see and browse results. Special operations like navigating though nodes taking more than 80% time should be provided as actions in popup menu/toolbar. There they are both discoverable and configurable. BTW I agree that clicking on small tree expansion icons many times is confusing - that's why JTree allows the same using keyboard (right arrow for expansion), it's much easier. Changing to RFE - please provide any additional information that you think may be relevant.
Milestone cleanup: future->next
Just added two actions - Expand Plain Path (expand the path as long as there's just one child node) and Expand Topmost Path (expand the path to the first leaf, according to the current sorting) which should address this RFE.