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.
Summary: | Merged CPU results | ||
---|---|---|---|
Product: | profiler | Reporter: | iformanek <iformanek> |
Component: | Base | Assignee: | issues@profiler <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | claudio4j, ghirschhorn, gsporar |
Priority: | P3 | ||
Version: | 4.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
iformanek
2005-02-18 17:43:17 UTC
I believe this is planned for 1.0, right? Yes, if time permits (not a defining or target feature). Not for 1.0 This is also useful cases where the same work is distributed over many threads. In many of these cases, only an aggregate tree can show the high-level method that is the cause of a performance problem, or at least the starting point for digging further. *** Issue 117409 has been marked as a duplicate of this issue. *** From issue 117409: Feedback from user: I still have the same problem in Netbeans 5.5.1: I am trying to optimize a web application that runs in a number of worker threads and that makes calls to back-end servers such as data base or EJB servers. The following feature would help a lot: A Call Tree view that shows an aggregate over all the worker threads in my server. This would give me a chance to find the methods that consume the most time by top-down opening the call tree. As it is, this deficiency conspire to make it difficult to find the methods that actually take the most total time: the Call Tree view is spread out over many threads that I must inspect individually to locate the worst method. Apart from this, I found the profiler easy to work with (especially compared to Eclipse TPTP, which I have used before and which insists on recording every single function call instead of an aggregate). Milestone cleanup: future->next Implemented in the new profiler. |