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.
[recent sources, NB4.1, JDK1.4.2, free form project, Linux] During profiling, the absolute timer behaves quite strangely: 1. The values it provides seems not to be correct (they seem to be to small). 2. The absolute time can even be lower after getting new result (for example it can go from 260ms to 259ms, etc.) The CPU time seems to be OK (at least for the first sight). I am attaching screenshot showing the situation. Note: the profiled application is still running.
Created attachment 19617 [details] Screenshot with profiled application times.
It seems that on Solaris the absolute timer works OK.
Probably connected problem: also the time in the threads combo behaves very strangely, after getting results, the absolute thread time is 0, after clicking on the combo it gets (seemingly random) negative value.
One comment, so far just FYI: the thread CPU time is badly wrong in this example. Thread CPU time can never be greater than absolute time, because it is, roughly speaking, a proportion of absolute time that the given thread's user code executes. The values for CPU time shown here are garbage, but hopefully this should be fixed by one of my today's putbacks. Also, on Linux, unlike other OSes that we support, there is in fact no real thread CPU timer (currently at least). So we should see the same values for absolute and thread CPU times.
Ok, I've just tried the latest JFluid version on the javac application running on Linux (using remote profiling) and reported results seem to be correct. Please try your test again, and let me know how it worked. Thanks, Misha
Well, it works differently than before, but not much better. I have tested three applications: 1. Java2D demo: a) The absolute times and CPU times looked acceptable, but the absolute time != CPU time. The difference was several milisecond. b) In the thread combo, the absolute time != absolute time in the root of CCT, and this time even was lowered as time runned (it was not constatly growing). 2. Trivial application, simple infinite loop printing "1" to the output (I will attach this application's project, the project requires NB4.1, but the class itself should work everywhere): a) the absolute and CPU time were similar, but (obviously) not correct. After several seconds of profiling, the profiler claimed that only a small time was consumed. b) the times sometimes can go lower. c) once it even happened, that all time were zero. 3. My "Generator" application (it is too big to be attached, I can send it to you offline). It behave similarly to the trivial application, only the numbers were a bit different. I am also attaching screenshots for case 2a and 2c. All performed on Linux, JDK1.4.2, NB4.1 (recent build).
Created attachment 19636 [details] Screenshot from situation 2a
Created attachment 19637 [details] Screenshot from situation 2c
Created attachment 19638 [details] The testing "trivial" application.
Well, using a recent sources, the problem seems to be gone (including the combo). It still seems that the absolute timer != CPU timer (usually there is difference a few miliseconds), but I guess this is caused by some system insufficiencies.
.