This was originally an email I sent to .NET team in my company, then decided to share as a blog post.
- Let’s say you have a complex application, and this application (or part of it) runs very slowly. No bug s in results, no errors or exceptions, but it just so slow! Now you want to know which part of your code is the reason, which method(s) you need to go and modify., which methods take so long to execute or consume so much memory/CPU. How would you know that?
- Let’s say you want to improve the performance of your application in general (say add caching or such), so, you want to identify which parts of your code deserve your attention and will really make difference (so that you don’t waste your time on optimizing something that will not have big effect in performance), for example, you might want to identify which methods are called more than others from different parts of your code. How would you do that?
How to solve it, or, what is a profiler (v. short):
It is an application that you can run along with your own program. It’ll track all method calls and how any method call other method and most importantly how long each method call will take, and how it consumes resources.
There are many .NET profilers out there.
- One of them is provided by Microsoft itself. It’s a bit old but works: CLR Profiler
- Another is DotTrace, this is the best .NET profiler ever! Used by the real gurus out there, like the guys running stackoverflow.com (which is run on asp.net mvc BTW). It’s created by JetBrains, a company that create treasure developer solutions
- But it’s NOT FREE
- Check it out anyway! Homepage: http://www.jetbrains.com/profiler/
- Another FREE one is EQATEC. This is very nice simple profiler that I wrote this message for. It focuses on measuring code speed and method call sequence not memory usage
So, what about EQATEC:
Quoting from homepage:
Spot slow code
Are you a .NET developer? Would you like your application to run faster? Then use our free profiler to spot you app’s slow code.
Point and go
No source code changes are needed. Just point the profiler to your app, run the modified code, and get a visual report.
Speedup any .NET app
As the only code profiler in the world, our profiler can even handle Compact Framework applications.
To use it with ASP.NET application, all you need to is:
- to put the path of the “bin” folder of your website as “App Path” (no need for source code or debug files), then it shows a list of all assemblies in it so you choose the DLL(s) you want to profile, and click “Build” at the right corner of the screen:
- Click “Open output folder” on the bottom left corner, copy the DLLs from there to your website “bin” folder
- Alternatively you can click “App Options” and set the output folder to “$(AppDir)” so that the generated files replace the old one
- You need to repeat these previous steps if you build the website again using Visual Studio
- run the website and start using it for a while
- go to EQUATEC “Run” tab and click “Take Snapshot
- go to the “View” tab and start reading the results
- for more information check the user guide: http://www.eqatec.com/tools/profiler/guide
It might be important also to spot the limitations:
This is a list of known limitations and problems in version 2.0.
- Blocking methods, such as Read(), will be counted as the total time, including the time the thread spends being descheduled and waiting for the call to complete. For now, you will have to recognize and judge situations like this manually.
- No debug information is available for the profiled assemblies. It means that you cannot debug the profiled versions – but you would probably not like to do that, anyway.
- No Visual Studio integration yet. We are looking into providing an add-in that will make it even easier to enable profiling your solution’s assembly files.
- No full method signature is displayed yet. So if you have several overloaded methods by the same name, or use generic methods, you cannot easily distinguish them as their signature (the method’s parameter list) is not displayed anywhere.
- Only defined methods are currently profiled, not referenced ones. So all the methods that your application itself defines will be profiled, but not System.* etc.
I hope this is useful for some of you as it was a real saver at times to me. Thank you very much!