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 79433 - analyze performance returns sligtly wrong time periods
Summary: analyze performance returns sligtly wrong time periods
Status: RESOLVED WONTFIX
Alias: None
Product: profiler
Classification: Unclassified
Component: Base (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: J Bachorik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-29 15:47 UTC by Pavel Rehak
Modified: 2007-01-09 13:21 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
snapshot (1.66 KB, application/octet-stream)
2006-06-29 15:48 UTC, Pavel Rehak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Rehak 2006-06-29 15:47:39 UTC
Product Version         = NetBeans 5.5 Dev (Build 200606290200)
  Operating System        = Windows XP version 5.1 running on x86
  Java; VM; Vendor; Home  = 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-b02;
Sun Microsystems Inc
profiler 5.5 beta (060629)
-
im profiling this sniplet of code:

public void fill() {
         for (int i=0;i<1000000000;i++) {
            rlist.add(new ArdaRoom("","",i));
        }
}

Profile Project | Analyze Performance | Part of Application
(selected just my fill method)

according to attached snapshot 
is sum(time) of all subnodes of fill()          9074
but total time of fill() counted by profiler is 9055
also percentage sum of time is over 100% (100,6%)

i've been fiddling with lenght of cycle etc, it didn't help
recalibration of used jdk didn't help either
Comment 1 Pavel Rehak 2006-06-29 15:48:35 UTC
Created attachment 31515 [details]
snapshot
Comment 2 J Bachorik 2007-01-09 13:03:12 UTC
Reproduced the decribed behavior. The difference observed is dependent on the
number of iterations executed. When I decreased the number of iterations to
500000 the time difference wasn't visible at all. This leads to a conclusion
that the time compensation used in profiler engine is flawed somehow and doesn't
work correctly for high numbers of extremly short iterations. The only way to
fix this would be to come up with with a different time compensation heuristics.
Comment 3 Jiri Sedlacek 2007-01-09 13:21:39 UTC
The solution of this problem may be in excluding simple methods from profiling 
as mentioned in Issue 66475. Created a RFE: Issue 92108.