Process Hacker Forums

I have two scripts that do basically the same thing: The first one ('onDemand'), uses a small amount of CPU whenever it's informed a certain event occured, and is completely idle the rest of the time. The second one ('poller') uses a very small amount of cpu, but poll's for its event so it's active constantly (you can see it's using background CPU in the screenshot).

I started them at more or less the same time and left them running for a day to test which one had less system impact, and I'm confused by the results (see screenshot, onDemand is first, poller is second: http://imgur.com/a/7tF34 )

OnDemend used vastly more "Total CPU Time" but vastly less "Cycles"; How can this be? 'Cycles' seems pretty solidly defined, but what exactly is CPU Time measuring here? Based on these numbers how can I tell which process has used fewer CPU resources; in terms of slowing the system down and total energy used by the CPU?

Thanks!

Always set Hacker -> Options -> Advanced -> Enable cycle-time CPU usage to OFF or you will get an incorrect measurement result for any CPU with a variable cycle time (for example, if the CPU dynamically changes the clock frequency).

Op here: My understanding is that setting only affects the cpu usage percent, not the "Total CPU time" or the cycle count. Toggling the setting does not seem to change those two columns. It does remove the 'poller' script's CPU use percentage, which normally sits at ~.5% when using the 'cycle based' setting. This must be incorrect, since the poller is clearly using some CPU.

Further reading ( viewtopic.php?f=5&t=2437 ) and ( https://www.microsoftpressstore.com/art ... 8&seqNum=5 ) seems to indicate the "total CPU time" reading is inaccurate, (and in the case of low-usage processes, grossly inaccurate) so I've turned it off. It's a pity, because it's a much more readable format than the cycle count.

This setting affects the correct timing of the operations, because The number of clock cycles required to execute each CPU instruction is fixed and depends on the set of control signals stored in the ROM of CPU-dependent control signals depending on the circuitry of the CPU and the hardware-implemented algorithm for sampling its rows.

When the Cycle-based mode is selected, the time estimate is based on calculating the number of spent CPU cycles, assuming that the latter operates at the nominal clock frequency, and when it is turned off, the cycles of a hardware timer with a fixed clock frequency are considered, which significantly reduces the measurement error.

And to assert that the measurement error in the case of a Cycle-based measurement scenario is equal to a certain value, since under an environment of variable computational load it is not even possible to approximately estimate the average duration of the CPU clock cycle, while the accuracy of counting the number of clock cycles is equal to plus or minus one low order (LSB.) counter, since if the signal "STOP" goes to the counter before it arrives, the counting input of the synchronous pulse is one LSB is lost, after - added to the value in the counter.