Innacurate profiler results
tesract
Posts: 7
When using the Ants profiler on our large gui application it consistantly shows line that are extremely fast outside the profiler as the slowest since they are inside of loop. There seems to be a lower limit on how little the profiler will attribute to a given line. Since our application is so large any profiles I run are filled with loops that when timed outside of the profiler are in fact extremely fast even in debug mode.
I created a small app to test the profiler on loops the following two functions are the most relevant:
private void button1_Click(object sender, EventArgs e)
{
int[] arr2 = new int[1000000];
DateTime start = DateTime.Now;
for (int i = 0; i < 100; i++)
for (int j = 0; j < 1000000; j++)
{
arr2 = arr;
}
DateTime end = DateTime.Now;
label1.Text = ((TimeSpan)(end - start)).TotalMilliseconds.ToString();
}
private void button2_Click(object sender, EventArgs e)
{
int[] arr2 = new int[1000000];
DateTime start = DateTime.Now;
for (int i = 0; i < 100; i++)
arr.CopyTo(arr2, 0);
DateTime end = DateTime.Now;
label1.Text = ((TimeSpan)(end - start)).TotalMilliseconds.ToString();
}
When running in debug mode, or release mode the times reported by button2_Click are consitently slower than button1_Click. Yet in profiling in either debug or release mode button2_Click shows as magnitudes faster than button1_Click.
From what I can figure ANTS must run by breaking between each line of code and calculating the time it took for that line, is there possibly a way to instead break every 10ms or 100ms and just figure out where the code currently is. Or perhaps some other way to work around this issue?
As it stands ANTS isn't helping us profile our application since the results are polluted with by the innacuracies of loops like the above.
I created a small app to test the profiler on loops the following two functions are the most relevant:
private void button1_Click(object sender, EventArgs e)
{
int[] arr2 = new int[1000000];
DateTime start = DateTime.Now;
for (int i = 0; i < 100; i++)
for (int j = 0; j < 1000000; j++)
{
arr2 = arr;
}
DateTime end = DateTime.Now;
label1.Text = ((TimeSpan)(end - start)).TotalMilliseconds.ToString();
}
private void button2_Click(object sender, EventArgs e)
{
int[] arr2 = new int[1000000];
DateTime start = DateTime.Now;
for (int i = 0; i < 100; i++)
arr.CopyTo(arr2, 0);
DateTime end = DateTime.Now;
label1.Text = ((TimeSpan)(end - start)).TotalMilliseconds.ToString();
}
When running in debug mode, or release mode the times reported by button2_Click are consitently slower than button1_Click. Yet in profiling in either debug or release mode button2_Click shows as magnitudes faster than button1_Click.
From what I can figure ANTS must run by breaking between each line of code and calculating the time it took for that line, is there possibly a way to instead break every 10ms or 100ms and just figure out where the code currently is. Or perhaps some other way to work around this issue?
As it stands ANTS isn't helping us profile our application since the results are polluted with by the innacuracies of loops like the above.
Comments
Sorry for the delay. We've been aware of the issue with tight code loops for some time. This will be addressed in version 2.7, along with the second-most-common cause of timing inconsistencies: recursive functions.
One solution to your problem might be to delete the pdb file. This prevents ANTS from instrumenting the IL, but it can still get method times. These method times will then be accurate.
Red Gate Software