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.
When browsing CPU Profile results (Java 2D demo), both Class level view and Package level view give strange percentual results (root element 100%, first child node > 100%).
Fixed, the updated code will become available in Milestone 2 release.
Now the child nodes values don't exceed the parent's value, but the sum of childs values can be significantly less than parent's value. Example: When browsing the CCT in package-view mode, some inner node reports 0.8% while sum of its children values is only 0.4%. The same problem ocurrs also in method-view and class-view mode. Maybe it is caused by rounding small values to zero. If there is a lot of these roundings on nodes at some tree level, their parent's value is significantly affected.
Not an issue. The percentage for a method is the ratio of its "inclusive" time to the total time. Inclusive time is a sum of the method's "self" time (how much this method itself was executing) and its callees' inclusive times. If the method's self time is high, then the sum of its children's percentages would certainly be less than the total method's percentage. Example: main() - 100% - 10 ms self - 20 ms inclusive foo() - 25% - 5 ms self - 5 ms inclusive bar() - 25% - 5 ms self - 5 ms inclusive In this case main() itself takes 50% of execution time (because its self time is 10ms), and its children take 25% each. But the percentage that we report in JFluid is for the method's inclusive time.
This is still unclear - from the user perspective, a drilldown to a level below is uderstood as a "full content of the node" and if the sum of subnodes is not 100%, it is confusing - the tree UI is not intuitively communicating the fact that a node has a value on its own in addition to the sum of values of subnodes. I'd suggest to try alternative approaches, e.g. creating a subnode "self execution" with the data of the method itself. A nice sideffect of that would be that the user would see, the correct order of where most of the time was spent, including the method's self time (i.e. the self time would be in the right position with regards to the submethods called).
I don't think this is an urgent issue at all, so I am changing its priority to P4.
Let's try to address this as part of move to use TreeTable
Planned for M3
Fixed for M3. Self time is now visualized as a separate child node.
Verification of old issues.
Closing old issues.
Reverting to the original Target Milestone value changed by mistake. Sorry for inconvenience.