How can we help you today? How can we help you today?
Robert C
Hi Nick, I'm afraid I don't know of a straightforward reason why you're having these problems, but if you're happy to do a little debugging, then maybe we can help... If you can download Process Explorer: http://www.microsoft.com/technet/sysint ... lorer.mspx Then, start profiling your ASP.NET application, and run Process Explorer. In the list of processes, you should find "inetinfo.exe", and then further "aspnet_wp.exe". If you choose "Show Lower Pane" from the view menu, then set "Lower Pane View" to "DLLs", you should get a list of the DLLs loaded for the currently selected process. If you select the aspnet_wp.exe (the ASP.NET worker process), could you confirm whether mscoree.dll appears (and that its version is the same as you expect), and further whether RedGate.Profiler.Core2.dll does? Another test is to check the security settings and environment variables for the ASP.NET process. If you right click on it and choose properties, the Security tab should show "User" as being "<your-machine-name>\ASPNET". Similarly, on the Environment tab, could you check whether "COR_PROFILER" is set on the list of variables? Sorry that this is a rather involved process, but with a bit of luck it will let us work out where the problem lies. Many thanks, Rob / comments
Hi Nick, I'm afraid I don't know of a straightforward reason why you're having these problems, but if you're happy to do a little debugging, then maybe we can help... If you can download Process Ex...
0 votes
Hi, I've just tried out your code on ANTS Profiler 3, and I see the effect you're reporting. However, after looking a bit closer, let me explain why it's there. When profiling at line-level, we obviously introduce an amount of overhead into your application - this is necessary, as we need to record timing data when every sequence point (analogous to a debugger breakpoint) is hit. In order to try and give you the most realistic idea of how your application will perform outside the profiler, we subtract the amount of time we spend in our code from the amount of time your method spends executing. This means that methods may be reported as taking less time in the results than they actually did when executing in the profiler - this is entirely correct. However, this approach can run into problems when there are multiple threads waiting on each other. When you asynchronously invoke a method, it is queued for processing on a worker thread. Calling EndInvoke() then causes the current thread to block until the result of that invocation is ready. Now, the problem here is that ANTS isn't directly introducing any overhead into that call to EndInvoke(), since it's effectively a Thread.Sleep, so we don't subtract any time from the wall clock time. However, the reason the EndInvoke takes longer than it would outside the profiler is of course that ANTS is introducing the overhead into the method being executed on the other thread. You can probably see that it would be difficult to detect these cross-thread dependencies! There is, however, something that can help: reduce the amount of overhead ANTS introduces. This is now easy to do in version 3 - profile in Fast Mode instead of Detailed Mode. This will only give you method level timings, but that is almost always sufficient to get you to the rough area of the problem, at which point I would recommend switching to detailed mode, and using a custom filter or the Visual Studio Add-in to profile only the methods or classes that you're most interested in. I'd also recommend using the hierarchy view - and in particular, the "time with children" columns. This lets you quickly navigate down to the areas of code causing you the most pain - there will almost always be one or two methods taking the vast majority of the time (in my experience at least). Note that any asynchronous invokes will "split" the hierarchy - in your example, AsyncInvoke() has no children, and AsyncCalc() has no parents, whereas SyncInvoke() shows SyncCalc() as a child. This is expected - we define method calls in the same way as the .NET runtime, which doesn't include cross-thread invocations (there's actually a lot of other stuff going on behind the scenes when you do that!). I hope that goes some way to explaining the results you're getting. Regards, Robert / comments
Hi, I've just tried out your code on ANTS Profiler 3, and I see the effect you're reporting. However, after looking a bit closer, let me explain why it's there. When profiling at line-level, we obv...
0 votes