Profiling performance (Detailed vs. Fast in ASP.NET)

Baard

Hi,

I’m getting practically no difference in performance between detailed and fast mode profiling.
It is an ASP.NET Web Application, and it uses about 3-4 seconds without profiling and about 70 sec. in either detailed or fast mode.

I’m using ANTS Profiler 3.1.0.20, ASP.NET 2, Visual Studio 2005

/Br, Bard

Brian Donahue

Hi Bard,

You may not see much difference between slow and fast mode depending on how the application is compiled and what it is doing. The major difference between slow and fast mode is the amount of instrumentation done to the code and the enabling of JIT optimizations like inlining. With ASP .NET applications, there are several possible issues at play:

• If the web.config sepcifies DEBUG=True, the code may not be compiled in an optimized way; lessening the effect of fast mode
• When web applications first start up, there is lots of set-up work for ASP .NET to do. You may see improvements in fast mode over time because you are making more requests for methods after all of the set-up work is complete.
• Your application may have some time-based events in it, where it wouldn't make any difference if you were using fast mode or not because you are waiting long periods of time for some resource or other.

Normally, fast mode boosts the time taken to profile an application the greatest simply because it allows JIT inling to occur -- so if the performance is negligable, I'd suggest looking for reasons why your ASP .NET code would compile without inlining first.

Baard

Hi,

There’s no difference between fast and detailed mode for me.
I experienced this in the application I was working on, but since it was in a virtual environment (which I assumed could affect the profiling performance) I therefore created a small test app outside the virtual machine to test this.

I had the debug set to true. I have now set it to false but it had little effect.

As for the overhead of startup, I only measured the time of a postback to the page instead (ignoring the load time), repeating the work of the initial load. This time both methods improved with about 10 sec. to approx. 60 sec. and the control run without profiler ran a second or two faster taking only about 2 sec.

There are no time based events.

I f you’d like I can send you my test project and perhaps you can see why it performs like it does.

The app is very simple. It loads a single page. During load it calls three methods, all manipulating dynamically created controls.
Although its’ not exactly a real life example, I only created it after experiencing the same in our development project application.

/Br, Bard

Brian Donahue

Hi Bard,

One thing is for sure -- virtual environments will affect the times reported by any code profiler. The problem is that the time is not being counted when the virtual machine gives up the CPU to another process. This makes for inaccurate results just about all of the time. I wouldn't test a code profiler on a virtual machine except just to verify the functionality of it, because the times will be skewed.

Baard

Baard wrote:

... I therefore created a small test app outside the virtual machine to test this...

As I wrote, I suspected that the VPC might compromise the results myself and I made an independent test.

I tried to the best of my ability to adjust the test according to your previous arguments, but the result still remained the same.

/Br, Bard