Comments
Sort by recent activity
I think I have come across the potential source of this problem, which looks like a serious deficiency in ANTS. I will write it up here as it might be useful to your engineers.
Look at the two segements of code below:
public void test()
{
Console.WriteLine("Before try/catch loop: " + DateTime.Now.ToLongTimeString());
for(int j = 0;j < 1000;++j)
{
try
{
int k = Int32.Parse("123");
}
catch
{
}
}
Console.WriteLine("After try/catch loop: " + DateTime.Now.ToLongTimeString());
}
public void test()
{
Console.WriteLine("Before try/catch loop: " + DateTime.Now.ToLongTimeString());
for(int j = 0;j < 1000;++j)
{
try
{
int k = Int32.Parse("abc");
}
catch
{
}
}
Console.WriteLine("After try/catch loop: " + DateTime.Now.ToLongTimeString());
}
When run under the normal debugger, the first code segment shows that the times before and after loop are the same, essentially meaning that it took less than a second. (Int32.Parse coverts the number string to an integer).
Then second code segment, which will generate an exception that is "caught" (because "abc" is not a number), shows the time before and after difference as about 5 seconds.
When run under ANTS, both segments report about 0.7 seconds. It seems that the time wasted by .Net for the exception is not taken into account. If this can be duplicated by you, I would consider it serious problem as code like this could potentially be the source of a slowdown in an application under test if a block like that happens to execute too many times. / comments
I think I have come across the potential source of this problem, which looks like a serious deficiency in ANTS. I will write it up here as it might be useful to your engineers.
Look at the two sege...
Robert:
I appreciate you trying to look at this, however, there is absolutely something strange with what is happening when running under ANTS. Having code that generates exceptions that are caught is a normal programming practice. Using a profiler should not yield wildly different results. I changed my test segment to use ticks and ran 3 tests. The results prove to me that ANTS is "interfering" with the normal flow of the code:
int n1 = Environment.TickCount;
for(int j = 0;j < 1000;++j)
{
try
{
int k = Int32.Parse("adf");
}
catch
{
}
}
int n2 = Environment.TickCount;
MessageBox.Show("Before/After: " + n1.ToString() + " / " + n2.ToString());
Test 1: Debug release, press "Start debugging" toolbar button:
Message box shows about 4000 ticks difference
Test 2: Release build, press "Start debugging". Message box shows about 3000 ticks difference.
Test 3: Profile Debug build under ANTS. Message box shows about 150 ticks difference.
From this it appears that ANTS is actually causing the timing or execution of the code segment to change. IMHO, that's awful.
Lee / comments
Robert:
I appreciate you trying to look at this, however, there is absolutely something strange with what is happening when running under ANTS. Having code that generates exceptions that are caught...
Brian:
Let me go a step further. I just changed my routine so the the code between the two Console.WriteLine's did nothing:
Console.WriteLine(DateTime.Now.ToLongTimeString());
for(int i = 0; i < 160000000; ++i)
{
}
Console.WriteLine(DateTime.Now.ToLongTimeString());
When run under debug, the Console.WriteLine show the same hh:mm:ss. In other words, the loop takes almost no time. (it's actually about 0.4 seconds). However, when run under ANTS, it reports that the event handler takes over 50 seconds. That's over 100 times too big. The reported results just don't make sense. / comments
Brian:
Let me go a step further. I just changed my routine so the the code between the two Console.WriteLine's did nothing:
Console.WriteLine(DateTime.Now.ToLongTimeString());
for(int i = 0; i < 16...
Yes, you are mistaken. Perhaps I wasn't clear. Please be aware that I am quite experienced with your product and what is being reported is just wrong. In the "All methods" screen, the line for this event hander is:
Method Time(sec.) Time w/childeren Hit Cnt
FormTooltipTest2.btnAdd300Rows_Click 0.0071 0.7725 1 / comments
Yes, you are mistaken. Perhaps I wasn't clear. Please be aware that I am quite experienced with your product and what is being reported is just wrong. In the "All methods" screen, the line for this...
Brian:
I do not understand what you are asking. The entire event handler attached to this button click is:
private void btnAdd100Rows_Click(object sender, EventArgs e)
{
LeerGridItem[] algi = new LeerGridItem[300];
LeerGridItem lgi;
for(int i = 0; i < 300; ++i)
{
lgi = new LeerGridItem(new Object[] { "Line " + n.ToString(), "Two", DateTime.Now, 7, DateTime.Now });
algi = lgi;
++n;
}
Console.WriteLine(DateTime.Now.ToLongTimeString());
leerGridView1.Items.AddRange(algi);
Console.WriteLine(DateTime.Now.ToLongTimeString());
}
If I run under debug and breakpoint at the "AddRange" line and single step over that line, the debugger comes back in about 5 seconds. From a standpoint of the profiler, why should it matter what code is doing in that AddRange method? Most of the code behind the AddRange I wrote myself and I am not using multiple threads. I am, however, using a third party grid control contained in another dll. Again, I don't see why that should matter. Please explain if I am mistaken. However, it seems like if a single statement does not return for 5 seconds, that the profiler should say that statement took 5 seconds. / comments
Brian:
I do not understand what you are asking. The entire event handler attached to this button click is:
private void btnAdd100Rows_Click(object sender, EventArgs e)
{
LeerGridItem[] algi = new L...