Innacurate profiler results

tesracttesract 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.

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hello,

    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.
  • great, if possible please keep me informed of any alpha or beta versions that become available for 2.7
  • I just got version 2.7. This problem still exists. button1_Click still profiles at 65 times slower than button2_Click. Is there any chance this can be fixed or should I find another product?
  • Breaking every 10ms and working out what line you are on cannot give hitcounts or accurate times, which is why we chose instrumentating the IL directly rather than random sampling.

    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.
    Jason Crease
    Red Gate Software
Sign In or Register to comment.