Develop Reference

C# Performance counter for CPU usage (processor time) how does the RawValue relate to the NextValue()?

I've been trying to grab the CPU usage of a process to verify it isn't hanging. The method NextValue() seems to be the recommended approach, but it seems to only get the CPU usage at the time of checking, and not the total CPU used in between checks (experimentation code and results below)
I ran the following code to see If I could figure out the relationship between the two values, but I can't seem to tell if they actually relate to each other directly. I can tell that 'foo.TotalProcessorTime' does seem to line up with counter.RawValue exactly.
var foo = Process.Start("MyProces.exe");
PerformanceCounter counter = new PerformanceCounter("Process", "% Processor Time", foo.ProcessName, true);
decimal totalValue = 0;
while (true)
{
var newTotal = counter.RawValue;
var increment = counter.NextValue();
var theoryTotal = totalValue + (decimal)increment*10000;//tried 10,000 and 100,000
logger.Info($"New Total: {newTotal} increment {increment} oldTotal + increment {theoryTotal} difference {newTotal-theoryTotal}");
totalValue = newTotal;
await Task.Delay(100);//different increments don't seem to affect the magnitude of NextValue
}
The following is my experimentation of NextValue(), the logs on the right are for the 1s interval, on the left is a 10s interval, with me doing the same things on the process in question.
counter.NextValue();//initialize
while (true)
{
await Task.Delay(10000);//tried 1s and 10s intervals, greater values on the 1s interval
logger.Info($"Percentage: {counter.NextValue()}");
}
TL;DR; How is NextValue() derived from RawValue? Or are they metrics that measure the same things but in a completely unconnected way? And if NextValue() really measures the value in between calls of NextValue() why am I getting '0's when I use a long interval between measurements and leave the process alone at the time of referencing NextValue()?

Time elapsed between two functions

I need to find the time elapsed between two functions doing the same operation but written in different algorithm. I need to find the fastest among the two
Here is my code snippet
Stopwatch sw = new Stopwatch();
sw.Start();
Console.WriteLine(sample.palindrome()); // algorithm 1
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);//tried sw.elapsed and sw.elapsedticks
sw.Reset(); //tried with and without reset
sw.Start();
Console.WriteLine(sample.isPalindrome()); //algorithm 2
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);
Technically this should give the time taken for two algorithms. This gives that the algorithm 2 is faster. But it gives different time if I interchange the calling of two function. Like if I call algorithm2 first and algorithm1 second it says algorithm1 is faster.
I dont know what I am doing wrong.

I assume your palindrome methods runs extremely fast in this example and therefore in order to get a real result you will need to run them a couple of times and then decide which is faster.
Something like this:
int numberOfIterations = 1000; // you decide on a reasonable threshold.
sample.palindrome(); // Call this the first time and avoid measuring the JIT compile time
Stopwatch sw = new Stopwatch();
sw.Start();
for(int i = 0 ; i < numberOfIterations ; i++)
{
sample.palindrome(); // why console write?
}
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds); // or sw.ElapsedMilliseconds/numberOfIterations
Now do the same for the second method and you will get more realistic results.

What you must do is execute both methods before the actual calculated tests for the compiled code to be JIT'd. Then test with multiple tries. Here is a code mockup.
The compiled code in CIL format will be JIT'd upon first execution, it will be translated into machine code. So testing it at first is in-accurate. So let the code be JIT'd before actually testing it.
sample.palindrome();
sample.isPalindrome();
Stopwatch sw = Stopwatch.StartNew();
for (int i = 0; i < 1000; i++)
{
sample.palindrome();
Console.WriteLine("palindrome test #{0} result: {1}", i, sw.ElapsedMilliseconds);
}
sw.Stop();
Console.WriteLine("palindrome test Final result: {0}", sw.ElapsedMilliseconds);
sw.Restart();
for (int i = 0; i < 1000; i++)
{
sample.isPalindrome();
Console.WriteLine("isPalindrome test #{0} result: {1}", i, sw.ElapsedMilliseconds);
}
sw.Stop();
Console.WriteLine("isPalindrome test Final result: {0}", sw.ElapsedMilliseconds);
Read more about CIL and JIT

Unless you provide the code of palindrome and isPalindrome function along with the sample class, I can't do much except speculate.
The most likely reason which I guess for this is that both your functions use the same class variables and other data. So when you call the function for the first time, it has to allocate memory to the variables, whereas the next time you call some other function, those one time expenses have already occurred. If not variables, it could be some other matter, but along the same lines.
I suggest that you call both the functions twice, and note the duration only the second time a function is called, so that any resources which they need to use may have been allocated once, and there's lesser probability of something behind the scenes messing with the result.
Let me know if this works. This is mere speculation on my part, and I may be wrong.

measuring time across processes

I need to measure the communitcation latency between two processes on the same machine.The best way I have come up with is serializing DateTime.UtcNow (DateTime.Now seems to be so utterly slow that it extremely distorts my measurements) into the message and comparing it with the DateTime.UtcNow in the other process. Is this as good as it gets? Or is there a better way?

If your goal is to measure and compare exact times between processes, you should use the Windows API function QueryPerformanceCounter(). The values that it returns are synchronized between processes because it returns an internal processor value.
Stopwatch also uses QueryPerformanceCounter() in its implementation, but it doesn't expose the absolute values that are returned so you can't use it.
You will have to use P/Invoke to call QueryPerformanceCounter() but it's pretty easy.
The overhead of using P/Invoke is small. From the MSDN documentation:
PInvoke has an overhead of between 10 and 30 x86 instructions per call. In addition to this fixed cost, marshaling creates additional overhead. There is no marshaling cost between blittable types that have the same representation in managed and unmanaged code. For example, there is no cost to translate between int and Int32.
Since the value returned from QueryPerformanceCounter() is a long, there will be no additional marshaling cost from it, so you're left with an overhead of 10-30 instructions.
Also see this MSDN blog where it is stated that the resolution of UtcNow is around 10ms - which is pretty huge compared to the resolution of the performance counter. (Although I actually don't believe this is true for Windows 8; my measurements seem to show that UtcNow has a millisecond resolution).
Anyway, it is easy to demonstrate that P/Invoking QueryPerformanceCounter() has a higher resolution than using DateTime.UtcNow.
If you run a release build of the following code (run from OUTSIDE a debugger), you'll see that almost all the DateTime.UtcNow elapsed times are 0, whereas all the QueryPerformanceCounter() ones are nonzero.
This is because the resolution of DateTime.UtcNow is not high enough to measure the elapsed time of calling Thread.Sleep(0), whereas QueryPerformanceCounter() is.
using System;
using System.Runtime.InteropServices;
using System.Threading;
namespace ConsoleApplication1
{
internal class Program
{
private static void Main(string[] args)
{
for (int i = 0; i < 100; ++i)
{
var t1 = DateTime.UtcNow;
Thread.Sleep(0);
var t2 = DateTime.UtcNow;
Console.WriteLine("UtcNow elapsed = " + (t2-t1).Ticks);
}
for (int i = 0; i < 100; ++i)
{
long q1, q2;
QueryPerformanceCounter(out q1);
Thread.Sleep(0);
QueryPerformanceCounter(out q2);
Console.WriteLine("QPC elapsed = " + (q2-q1));
}
}
[DllImport("kernel32.dll", SetLastError=true)]
static extern bool QueryPerformanceCounter(out long lpPerformanceCount);
}
}
Now I realise that it could be that the overhead of calling QueryPerformanceCounter() is so high that it is measuring how long it is taking to call, rather than how long Thread.Sleep(0) takes. We can eliminate that in two ways:
Firstly, we can modify the first loop as follows:
for (int i = 0; i < 100; ++i)
{
var t1 = DateTime.UtcNow;
long dummy;
QueryPerformanceCounter(out dummy);
Thread.Sleep(0);
QueryPerformanceCounter(out dummy);
var t2 = DateTime.UtcNow;
Console.WriteLine("UtcNow elapsed = " + (t2-t1).Ticks);
}
Now the UtcNow should be timing Thread.Sleep(0) and two calls to QueryPerformanceCounter(). But if you run it, you'll still see almost all the elapsed times being zero.
Secondly, we can time how long it takes to call QueryPerformanceCounter() a million times:
var t1 = DateTime.UtcNow;
for (int i = 0; i < 1000000; ++i)
{
long dummy;
QueryPerformanceCounter(out dummy);
}
var t2 = DateTime.UtcNow;
Console.WriteLine("Elapsed = " + (t2-t1).TotalMilliseconds);
On my system it takes around 32ms to call QueryPerformanceCounter() one million times.
Finally, we can time how long it takes to call DateTime.UtcNow one million times:
var t1 = DateTime.UtcNow;
for (int i = 0; i < 1000000; ++i)
{
var dummy = DateTime.UtcNow;
}
var t2 = DateTime.UtcNow;
Console.WriteLine("Elapsed = " + (t2-t1).TotalMilliseconds);
On my system that takes around 10ms, which is around 3 times faster than calling QueryPerformanceCounter().
In Summary
So DateTime.UtcNow has lower overhead than P/Invoking QueryPerformanceCounter(), but it has much lower resolution.
So you pays your money and you takes your choice!

Performance profiling in .NET

I wrote a class which uses Stopwatch to profile methods and for/foreach loops. With for and foreach loops it tests a standard loop against a Parallel.For or Parallel.ForEach implementation.
You would write performance tests like so:
Method:
PerformanceResult result = Profiler.Execute(() => { FooBar(); });
For loop:
SerialParallelPerformanceResult result = Profiler.For(0, 100, x => { FooBar(x); });
ForEach loop:
SerialParallelPerformanceResult result = Profiler.ForEach(list, item => { FooBar(item); });
Whenever I run the tests (one of .Execute, .For or .ForEach) I put them in a loop so I can see how the performance changes over time.
Example of performance might be:
Method execution 1 = 200ms
Method execution 2 = 12ms
Method execution 3 = 0ms
For execution 1 = 300ms (Serial), 100ms (Parallel)
For execution 2 = 20ms (Serial), 75ms (Parallel)
For execution 3 = 2ms (Serial), 50ms (Parallel)
ForEach execution 1 = 350ms (Serial), 300ms (Parallel)
ForEach execution 2 = 24ms (Serial), 89ms (Parallel)
ForEach execution 3 = 1ms (Serial), 21ms (Parallel)
My questions are:
Why does performance change over time, what is .NET doing in the background to facilitate this?
How/why is a serial operation faster than a parallel one? I have made sure that I make the operations complex to see the difference properly...in most cases serial operations seem faster!?
NOTE: For parallel processing I am testing on an 8 core machine.

After some more exploration into performance profiling, I have discovered that using a Stopwatch is not an accurate way to measure the performance of a particular task
(Thanks hatchet and Loren for your comments on this!)
Reasons a stopwatch are not accurate:
Measurements are calculated in elapsed time in milliseconds, not CPU time.
Measurements can be influenced by background "noise" and thread intensive processes.
Measurements do not take into account JIT compilation and overhead.
That being said, using a stopwatch is OK for casual exploration of performance. With that in mind, I have improved my profiling algorithm somewhat.
Where before it simply executed the expression that was passed to it, it now has the facility to iterate over the expression several times, building an average execution time. The first run can be omitted since this is where JIT kicks in, and some major overhead may occur. Understandably, this will never be as sophisticated as using a professional profiling tool like Redgate's ANTS profiler, but it's OK for simpler tasks!

As per my comment above: I did some simple tests on my own and found no difference over time. Can you share your code? I'll put mine in an answer as it doesn't fit here.
This is my sample code.
(I also tried with both static and instance methods with no difference)
class Program
{
static void Main(string[] args)
{
int to = 50000000;
OtherStuff os = new OtherStuff();
Console.WriteLine(Profile(() => os.CountTo(to)));
Console.WriteLine(Profile(() => os.CountTo(to)));
Console.WriteLine(Profile(() => os.CountTo(to)));
}
static long Profile(Action method)
{
Stopwatch st = Stopwatch.StartNew();
method();
st.Stop();
return st.ElapsedMilliseconds;
}
}
class OtherStuff
{
public void CountTo(int to)
{
for (int i = 0; i < to; i++)
{
// some work...
i++;
i--;
}
}
}
A sample output would be:
331
331
334
Consider executing this method instead:
class OtherStuff
{
public string CountTo(Guid id)
{
using(SHA256 sha = SHA256.Create())
{
int x = default(int);
for (int index = 0; index < 16; index++)
{
x = id.ToByteArray()[index] >> 32 << 16;
}
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] y = new byte[1024];
rng.GetBytes(y);
y = y.Concat(BitConverter.GetBytes(x)).ToArray();
return BitConverter.ToString(sha.ComputeHash(BitConverter.GetBytes(x).Where(o => o >> 2 < 0).ToArray()));
}
}
}
Sample output:
11
0
0

Using QueryPerformanceCounter in c sharp but not getting precise results

I am using QueryPerformanceCounter to get the precise timing behaviour in my c sharp program. But if i measure the timing using thread.sleep it is not giving excpected results.
I followed standard example given at msdn site:
http://msdn.microsoft.com/en-us/library/ff650674.aspx
myTimer.Start();
for (int i = 0; i < iterations; i++)
{
// Method to time
System.Threading.Thread.Sleep(1000);
}
myTimer.Stop();
Results are :
Iterations: 5
Average time per iteration:
0.208957983452184 seconds
Datetime.Now gives :
Duration of test run:
5 seconds
5000 milliseconds
Can you please suggest what could be possible error?