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.

Bug 113880 - Filters do not work as expected for CPU profiling
Summary: Filters do not work as expected for CPU profiling
Status: REOPENED
Alias: None
Product: profiler
Classification: Unclassified
Component: Base (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: issues@profiler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-27 17:30 UTC by Alexander Kouznetsov
Modified: 2007-09-27 09:39 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Snapshot (100.25 KB, application/octet-stream)
2007-08-27 17:31 UTC, Alexander Kouznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kouznetsov 2007-08-27 17:30:39 UTC
Product Version: NetBeans IDE Dev (Build 200708270000) 
Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b06 
System: Windows XP version 5.1 running on x86; Cp1251; ru_RU (nb)

Performed steps:
- Direct Attach to NetBeans with the following customized CPU settings: Entire Application, Inclusive Filter
org.netbeans.modules.java.*, profile underlying framework startup, profile threads started after entering any of root
methods, do not limit threads
- RESULT: Live Results and Snapshot contain methods not only from org.netbeans.modules.java package but even from java
package.
Comment 1 Alexander Kouznetsov 2007-08-27 17:31:15 UTC
Created attachment 47498 [details]
Snapshot
Comment 2 J Bachorik 2007-09-24 12:47:39 UTC
this is caused by usage of "Profile Only Project Classes" filter
see issue #116501 for more details
Comment 3 Alexander Kouznetsov 2007-09-24 13:06:17 UTC
yardus, are these issues really connected? According to this description QuickFilter is used instead of Profile Only
Project Classes filter.
Comment 4 J Bachorik 2007-09-24 13:19:55 UTC
yes, you are right. my mistake :( had some troubles with refreshing IZ and filled the details to a wrong issue
Comment 5 Jiri Sedlacek 2007-09-26 15:18:59 UTC
Actually it works correctly, if you choose to "Profile threads started after entering any of root methods" all runnables
have to be instrumented to get the data from other threads and that's why run() methods from other packages appear in
results.

Just note that according to Issue 99314 the runnables are instrumented before any of the root methods has been executed.

Closing as INVALID because it works as designed.
Comment 6 Alexander Kouznetsov 2007-09-26 19:25:58 UTC
If I understand correctly, filters work even if root methods are filtered out. It would be nice if profiler wasn't
showing all the methods that do not conform filter even they're in new Runnables. Please, let me know if this should be
considered as enhancement and tracked as another issue. But I believe that this fits into this issue very well.
Comment 7 Jiri Sedlacek 2007-09-26 20:09:33 UTC
Ideally the methods filtered-out by instrumentation filter should not be displayed among profiling results. But it's 
not as easy at it seems at the first sight - since these methods take some time, not showing them in profiling results 
would break results consistency, for example sum of all relative times won't be 100%.

You may turn this issue into an ENHANCEMENT but till now we weren't able to find any reasonable solution. Also please 
note that "Profile threads started after entering any of root methods" option is in Advanced settings for advanced 
users which should understand what does this option mean and how it influences profiling results.
Comment 8 Alexander Kouznetsov 2007-09-27 09:39:08 UTC
Seems to be a nice enhancement.