Comments
Sort by recent activity
Can you please also ensure that debug="true" in your web.config? This is necessary for line-level timing. / comments
Can you please also ensure that debug="true" in your web.config? This is necessary for line-level timing.
Excellent! I'm glad ANTS Profiler has been able to (eventually) identify the problem. But anyway...
Between every IL branchpoint (which may be every line), ANTS Profiler instruments the IL to record the current time. This introduces an overhead of about 10ns per IL statement. Consequently, this slows down a typical program by around 3x. However, for programs with tight loops, lots of mathematics, or lots of method calls, this can be higher (e.g. 10x). You seem to be experiencing a 10x slowdown.
Compiling a SQL query is the kind of thing that introduces a lot of overhead. I imagine there are deep recursive methods, tight loops, etc - the kind of stuff ANTS Profiler hates. However, I've done some research and I'm pretty sure ANTS Profiler is the fastest line-level instrumentation profiler out there. Rivals were typically 2x to 40x slower than ANTS. I'm sorry that you've got a program that is as slow as possible for our profiler! To speed up profiling, I can suggest turning on Inlining in our options dialog, or profiling in method-level rather than line-level mode.
ANTS Profiler estimates and subtracts the overhead, hopefully leaving you with realistic results. So the fact it takes 100s outside the profiler, and ANTS says it takes 125s, is correct.
I don't think what you've seen is a bug. I think it's just that EF is a worst-case scenario for ANTS Profiler's speed. / comments
Excellent! I'm glad ANTS Profiler has been able to (eventually) identify the problem. But anyway...
Between every IL branchpoint (which may be every line), ANTS Profiler instruments the IL to rec...
Looking at your timeline, there is a suspicious dip in CPU usage at around 7 minutes, followed by around 180s of heavy CPU usage. Perhaps, there is 7 minutes of 'other activity' before your Page_Load? Have you tried selecting various regions within the period 2minutes -> 10 minutes? You may find that Page_load is only run in the last 3 minutes of execution.
Also, you might find RedGate.Profiler.UserEvents.dll. By referencing this dll in your sourcecode, you can make calls to static methods like RedGate.Profiler.UserEvents.SignalEvent("Page_Load is now starting"); These will then appear in your timeline. / comments
Looking at your timeline, there is a suspicious dip in CPU usage at around 7 minutes, followed by around 180s of heavy CPU usage. Perhaps, there is 7 minutes of 'other activity' before your Page_L...
Thanks for the screenshots! Yes, it is not as I described at all. But I think it can all be explained... somehow.
What caught my eye is the ThreadHelper.ThreadStart, with a hitcount of 1. If you unclick 'Hide Insignificant Methods', what is called within this thread? It appears as if this Thread is responsible for all the wall-clock time that is not used by your Page_Load. However, it has a very low CPU time, which is a bit odd. What going on in ThreadStart? / comments
Thanks for the screenshots! Yes, it is not as I described at all. But I think it can all be explained... somehow.
What caught my eye is the ThreadHelper.ThreadStart, with a hitcount of 1. If you...
Yes, I think your analysis is correct. PerformWaitCallback will run for the entire duration of your request. This consists of the two call stacks in the two different threads you identified: one containing OnStart, and the other containing ProcessRequest. You code should all be children of ProcessRequest, which our profiler says takes 3 minutes.
Firstly, if you haven't already, you may wish to change from 'CPU time' to 'Wall-clock time'. This is done by a combo-box in the bottom right corner. This should make both ProcessRequest and OnStart jump up to 8 minutes. This is because I think your code is probably making database calls which cause the ProcessRequest thread to block for a total of 5 minutes during execution. So you code takes 3 minutes of 'CPU time', but 8 minutes of 'Wall-Clock time'. Please get back to me with whether this works. / comments
Yes, I think your analysis is correct. PerformWaitCallback will run for the entire duration of your request. This consists of the two call stacks in the two different threads you identified: one ...
There have been some issues with localized Visual Studio, but given what you say I don't think this is the problem.
One solution might be to go to a command prompt in the VS2005 directory that contains devenv - probably at C:\Program Files\Microsoft Visual Studio 8\Common7\IDE, and type devenv /setup. This re-initializes all the menus, and will take about 20s. / comments
There have been some issues with localized Visual Studio, but given what you say I don't think this is the problem.
One solution might be to go to a command prompt in the VS2005 directory that cont...
What locality are your versions of VS? Are they both en-US? / comments
What locality are your versions of VS? Are they both en-US?
Awesome, using ZetaTest I've been able to repoduce both bugs you have reported. Thank you!
Both are caused by the same issue. Your program has more complex stacktraces than most programs - largely due to use of XML and Regexes. Consequently, when ANTS Profiler tries to draw the call tree of your stack traces, it quickly runs out of memory.
We will try to resolve this by trying improving the memory efficiency of ANTS Profiler. In the meantime, I can suggest the following:
1. Profile in 'Only methods with source (fastest)' mode. This uses only a fraction of the memory used by other modes.
2. Try using a x64 machine. Since ANTS Profiler will run as x64, there are no limits on its memory usage. / comments
Awesome, using ZetaTest I've been able to repoduce both bugs you have reported. Thank you!
Both are caused by the same issue. Your program has more complex stacktraces than most programs - largel...
Having lots of different stack traces isn't a bad thing - it is just often happens when using lots of XML and Regexes. I don't think this is a problem with Zeta Test, but just a problem with ANTS Profiler.
To reduce the complexity of the Regex calls, it might be worth trying to use RegexOptions.Compiled, if you do not do so already. This will probably give you a speed increase, and reduce the complexity of stacktraces. / comments
Having lots of different stack traces isn't a bad thing - it is just often happens when using lots of XML and Regexes. I don't think this is a problem with Zeta Test, but just a problem with ANTS ...
Ah... I managed to fix it by copying the contents of the C:\Documents and Settings\jason.crease\My Documents\Zeta Test\Stationary\ENU directory to C:\Documents and Settings\jason.crease\My Documents\Zeta Test\Stationary\ENG. / comments
Ah... I managed to fix it by copying the contents of the C:\Documents and Settings\jason.crease\My Documents\Zeta Test\Stationary\ENU directory to C:\Documents and Settings\jason.crease\My Document...