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.
There are times where I don't want any class instrumentation or redefinition whatsoever -- just simple "collect a thread dump every 10ms and aggregate the data" profiling for the whole app. NetBeans has a good profile results UI, etc, I shouldn't have to switch to a different tool in cases where I want simple, low-fidelity (but relatively quick) sampling profiling. This is especially true since the dynamic attach with Java 6 is compelling and other profilers don't yet have this. Also there are still cases where a bug in Java 6 causes the target JVM to crash when the profiler asks it to redefine classes, which sampling should work around -- though even without this bug there would still be a time and place for sammpling-based profiling.
This is also quite relevant if the "VisualVM" project (https://visualvm.dev.java.net) that was shown in a BOF at JavaOne 2007 is ever to come to fruition in this area. Most people expect both an instrumentation and profiling mode from any profiler.
Obviously the NetBeans team can disagree, but I'd posit this as a top-priority enhancement for NB 6.1.
In fact till this feature is not in NB Profiler I can't continue "trying" it.
I should be clear that I *need* this feature because I work with a system that is too large to instrument in its entirety -- it not only takes forever but the NetBeans profiler says something about having exceeded its limits on instrumented classes/methods and gives up! It is impossible to know the root methods to target up front in all cases -- even when you know the system well as sometimes you don't know the problem well. If you don't know the system well, then you're really sunk. A lightweight, low-fidelity sampling mode could allow the hotspots to be narrowed down enough to allow configuration of root methods. As it is now one is often just plain sunk and realistically has to use another tool.
A scaled down version of this feature should be built into NetBeans itself for purposes of allowing users to report performance issues against NetBeans. Currently NetBeans users gripe about performance but have trouble providing sufficient data for NetBeans developers to do anything about the problem. If there was a simple, "start/end performance sampling" control for this where the data could be attached to a bug report, performance complaints could be addressed much more readily. This scaled down version could be as simple as taking a full stack dump every 'n' seconds and doing some string canonicalization and compression to keep the data size down. Further processing could be postponed until a simple analysis tool for use by NetBeans developers. In the context of something like VisualVM, this scaled down version could be a really big boon for other products beyond NetBeans, i.e. my customers could use the same thing when complaining about my products' performance.
(In reply to comment #5) > A scaled down version of this feature should be built into NetBeans itself for > purposes of allowing users to report > performance issues against NetBeans. This is already implemented in NB 6.7. See issue #153221.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/547348abd2fc User: Tomas Hurka <thurka@netbeans.org> Log: issue #113276, CPU sampling implemented
Done for 7.1.