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.
On a notebook with power saving features turned on, especially with CPU changing frequency (e.g. Intel SpeedStep) the initial profiler calibration may measure and store different numbers than the right ones which should be used when the user starts profiling. On my notebook with Pentium M 1.7GHz I measured the following numbers when I repeated calibration three times for the highest and for the lowest CPU frequency: 1.7GHz: absolute timestamp - 5.215, 5.225, 5.2025 thread CPU timestamp - 5.4725, 5.24, 5.47 both timestamps - 9.4675, 9.49, 9.485 sampled instrum. mode - 0.1162, 0.1162, 0.1162 600MHz: absolute timestamp - 7.045, 7.0, 7.085 thread CPU timestamp - 7.1, 7.095, 7.0925 both timestamps - 13.8125, 13.84, 13.8325 sampled instrum. mode - 0.325, 0.325, 0.325 The numbers between 600MHz and 1.7GHz differ a lot and may cause significant distortion when used incorrectly. I have a suggestion: Let's ask the user at the time of the first calibration if she is running the IDE on a notebook with CPU changing frequency (or power saving in general) and in such a case either: * let the user switch between the power-saving profiles and do the calibration for each of them; asking the user for the profile currently in place before starting each profiling or * doing calibration before each profiling start
But, even the two options mentioned above don't solve the problem with automatic dynamic change of the frequency, for example done on Linux (e.g FC3) by cpuspeed daemon. On my notebook the frequency can automatically dynamically change up and down between a number of frequencies (600MHz, 1GHz, 1.2GHz, ..., 1.7GHz) based on the current CPU utilization by running processes. This could affect for example profiling of application startup. At the very beginning of the startup CPU would be running at 600MHz and after a few seconds it would be running at 1.7GHz.
In general, I don't think a machine that dynamically and automatically changes its speed is a proper vehicle for profiling. I think the only way to cope with this situation is to detect this capability in the machine (I suspect some Windows API for that exists; the trick is to find it) and warn the user. The tool should explain the problem and ask user to either turn this feature off (I guess it can be done), or run profiler on another machine. One thing that makes this problem less acute is the fact that calibration, being quite CPU intensive, is likely to switch the CPU to the highest frequency. That will mean that calibration data will always contain the smallest possible timing for instrumentation calls. This in turn will lead to relatively "reasonable" end results - that is, at least no zero or negative time for any user app methods due to instrumentation taking less time during profiling than during calibration. BTW, I wonder how you determined that this problem is P2. It doesn't seem like a showstopper for users who understands something about nature of CPU profiling.
> In general, I don't think a machine that dynamically and > automatically changes its speed is a proper vehicle for profiling. Unfortunatelly notebooks with modern CPUs will be more and more popular among developers I guess. At least here, almost all developers have new notebooks. > calibration, being quite CPU intensive, is likely to switch the CPU > to the highest frequency. That will mean that calibration data will > always contain the smallest possible timing for instrumentation calls. The switch from the lowest to the highest frequency is not immediate. Depends on setting of the deamon who does the switching. It takes some time before the high CPU utilization is detected. This means that the calibration data will be somewhere between the extremes. > I wonder how you determined that this problem is P2. It doesn't > seem like a showstopper for users who understands something about > nature of CPU profiling. I think this issue is quite dangerous because not all users may have a clue that their CPU speed is being switched up and down "randomly" :) If you explain this issue visibly in the UI (for example in the calibration dialog box), feel free to downgrade to P3.
Ok, I agree with your comments. I've just added a big warning in the calibration dialog about possible issues with a machine that has dynamically switchable CPU frequency. So I think we can now downgrade this to P3. A real solution to the problem should involve detecting this feature for sure (using appropriate Windows or Linux API I guess), and then either notifying the user about the exact problem, or maybe doing something smarter. Such as setting this frequency to a fixed value if it's possible.
We probably cannot do more than provide a way for the user to select "automatically perform calibration before each profiling", which would solve this at least partially - the case where the CPU frequency is changed during profiling would not be addressed, but at least the (more common) case where the laptop rnning on batteries uses different CPU frequency than when connected to power, would be solved.
will not do anything more in M7
Warning about possible problems with dynamic CPU frequency switching is now displayed everytime calibration is performed. I'm closing this issue and opening new one which suggests enhancement - ability to automatically perform calibration before each profiling session. Marking as fixed for M8.
I tried Profiler 1.0 RC1 with NB 5.0 and I don't see any warning. Reopening.
OK, I see it is there.
Profiler 070313