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.
I was profiling the fibonacci equation and I noticed the self time for the recursive calculate method (fib) was showing > 100% in the lower method list. This is using M6. The project is attached. I was profiling the entire application, excluding core Java classes.
Created attachment 21780 [details] Fibonacci Calculator Project
Thank you for reporting this problem. The code in question is now being deeply reworked; I will look at this once it is functioning again. BTW, please let me know which platform you ran on and at what moment you hit "get results". Thanks, Misha
Hi Brian, I've just tried this example, and it worked fine for me. Possible explanations are: 1. (Preferable :-)) The bug went away as a side effect of considerable revamping (for unrelated reasons) of the code that could, in principle, be responsible for this bug. 2. My environment is different from yours. I think the best way to resolve this would be to give you a snapshot of our current profiler code so that you can try this example again. Please let me know if that's ok with you and if so, which platform(s) you need it for. Regards, Misha
Sure Misha, send me your latest snapshot and I'll check it out. I'm on WindowsXP. /Brian
Brian, can I ping you regarding this issue? Thanks, Misha
Yes,sorry, I've just now tested the M7 build and am still seeing CPU percentages > than 100%. This is on Windows XP and NetBeans RC1. Note, the M6 profiler was installed. I created a new user dir and installed the M7 NBMs. I also had to set the application's libraray to use the JFluid VM (normally, this isn't the case, it just has to be set to use a 1.4.2 VM). Let me know if you'd like me to follow a different approach for testing. I've attached a graphic of what I'm seeing. /Brian
Created attachment 22054 [details] Graphic showing CPU time > 100%
The issue may be explained by incorrect calibration data (instrumentation execution time measured at calibration time much smaller than that in reality), caused by say dynamic CPU frequency adjusting or a similar reason. This needs to be verified as explained in more detail in the personal note to Brian.
Fixed in M7. Check the comment for the related IN carefully - this seems to be a pretty delicate area in the code. Although hopefully in real life such examples (deeply recursive calls of methods that do very little but calling other methods) are rare. Brian, you better use something more realistic for your Profiler demos - though this test was definitely worth looking at for me :-)
An update: my previous comment proved to be wrong. The problem was due to calibration data file corrupted for some reason. Time cleansing algorithm that I talked about in the previous comment works fine even for this example, and the profiler should not have problems dealing with tests like this one.
Verification of old issues.
Closing old issues.
Reverting to the original Target Milestone value changed by mistake. Sorry for inconvenience.