For those that don’t know, PerfView is a performance profiling tool that can be used to diagnose a broad range of performance problems. We released a free copy of this to the web back in January. Well, it has been over 6 months since that release and I have been busy adding various capabilities to the tool, so it was time to do a refresh, which we finished just today. The new release is V1.0.29. Click the
To get started. It is a single EXE packaged in a single ZIP file. You can literally be running PerfView in 5 mouse clicks (less if there wasn’t so many security dialog boxes).
- Click on the download link above
- Click on the downLoad button on that page
- Cick on the ‘Open file’ security dialog. This opens the PerfView.zip file
- Click on the PerfView.exe file inside the ZIP file
- Click on the OK button on the security dialog
When the app launches there is a ‘welcome’ page that tells you how to get started. It recommends you walk through the tutorial, and that is still excellent advice.
It is hard to overestimate how useful this tool is. I do .NET performance investigations LITERALLY FOR A LIVING, and this is the tool I turn to time and time again. Every time I need the tool to do something more, I improve the tool, so you are leveraging my man-years of hard-core performance work when you use the tool. People around the office joke that the first step of my answer to pretty much any performance problem is ‘use PerfView’. This is pretty close to the literal truth….
In previous blogs I posted some Getting Started Videos. You are welcome to download those too (I have promised to put them on the web in a way you can just watch them directly. I promise this will happen soon….)
For those of you are familiar with XPERF or is newer version, Windows Performance Analyzer (WPA). PerfView is a close cousin to XPERF/WPA. They both use windows Event Tracing for Windows (ETW) to collect a broad range of interesting events from the operating system, the CLR, and your application and display this wealth of information to you. Because they both are effectively different interfaces to the same underlying OS data collection, they both generate the ‘same’ data file (called .ETL files). Thus either tool can display the data from the other tool. The primary differences between the two tools is that PerfView has more support for Managed code. For example PerfView automatically turns on a good set of .NET Runtime events by default, and deals with generating symbolic information (NGEN pdbs). PerfView also knows how to take snapshots of the .NET GC heap so you can do memory investigations along with time-based (CPU/Disk) investigations
PerfView’s help menu lets you see the release notes so you can see exactly what has changed in the past year.. I am only going to hit the highlights here. Important improvements include
- Streamlined command line data collection: Originally PerfView was optimized for collecting and immediately viewing data on the same machine. It turns out that a VERY common scenario was to have someone else collect data, and send it to elsewhere for analysis. V1.0 of Perfiew could do this, but typically you wanted to specify more parameters (e.g /zip). Now the defaults are tuned for this case. To collect data you either do
PerfView Run YOUR_COMMAND_LINE
if you know what executable you want to run. PerfView runs the command and stops when the command completes. If you can’t easily run the command in that way (e.g. it is a service or a Metro applicationn) use
This starts collection, you can then run your scenario and then click the ‘stop’ button.
In either cases PerfView creates a ETL.ZIP file that is ready to copy to another machine. You can simplify the collection even more by throwing the /NoGui option, which avoids running any GUI, which makes mistakes even less likely).
- Support for .NET EventSources. I mentioned that YOUR app can also generated messages into the ETL file. This can be done in the .NET V4.5 (There is a release candidate of this here) I will talk more about in a future blog. For those who can’t wait, see System.Diagnostics.Tracing.EventSource and the Help -> Using Event Sources in the PerfView documentation. This is especially helpful for server applications.
- Support for blocked time. It is not uncommon that your problem is not CPU but Disk I/O or some other condition that causes you to block. PerfView can help you find these problems too. Again I will talk more about this is future blogs.
Over the next several weeks I will be going into more detail on these. In the mean time I strongly advise you to work through the tutorial if you have not already.
Happy Performance hunting.
.NET Performance Architect