Next Version of PerfView has been released!

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

PerfView Download Page

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).   

  1. Click on the download link above
  2. Click on the downLoad button on that page
  3. Cick on the 'Open file' security dialog.   This opens the file
  4. Click on the PerfView.exe file inside the ZIP file
  5. 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


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

PerfView collect

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.

Vance Morrison

.NET Performance Architect

Comments (15)
  1. Robert says:

    Another question: in you video it says Metric/msec should be low like 0.21 ..but on our production machine i see Metric/msec: 2.78

    The thing is, this is when the machine is actually only at 40% CPU, and nothing suspicious seems to be in the traces, any idea what gives ?

    The machine is:

    Windows Server 2008 R2 Standard


    8 core Xeon machine with 12GB of ram

    And keep those videos/docs coming's really appreciated ! 🙂

  2. I assume you are taking about the CPU view.   I don't remember talking about the CPU metric being low.  I said that if it is low, then CPU is not your more important thing to improve.  

    Note however that for server scenarios you are often thottled by incomming work (there is just no work to do).  What I said in the video is in the context of time period that you want to be as fast as possible (like an app doing a paritcular piece of work).   This only 'works' on a server if you either

      1) look at only the time of one request (thus it can't be throttled by no incomming work) OR

      2) Load the system so that incomming work is NOT scarse.  

    In general making sense of server loads is harder (but definate doable, I will probably post about it).  

    You mention that the metric/msec is 2.78.  That means that you are using almost 3 cores (I don't now how many your system has).   That is a high enough CPU load that CPU is certainly worth looking at.  

    As to whether 40% CPU utilization is good or bad, depends on the workload.    If this is an ASP.NET workload, you should definately start with the ASP.NET Stats page.   This will tell you if you are starved for work (the queue length will be 0 or 1).  If you are starved for work, then things are great!.  

    The help for the ASP.NET stats is non-existant.   It is on my TODO list, but hopefully much of it will 'make sense' without much explaination.    We will see..

  3. Robert says:

    Thanks for the reply

    Seem like my first post got lost ..i was wondering if there are any command line switches to enable the checkbox options we get when we manually launch perfview, since i only saw a handful documented in the help file to automate things from the command line in a production environment

    Again great news to see tools like this being made public. The help files and videos alone are invaluable. Just a few days ago i only knew about apps from 3rd parties, and windbg which is just way beyond me little web developer to wrap my head around.

    In those few days i discovered xperf, perfview, performance monitor, and now just came across debug diag which i will give a try too.

    It's nice to see the tools get easier to use (with help and example usages), so we can quickly get back to developing sites, instead of spending weeks on steep learning curves for things like windbg, that we might eventually just use like once a year.

  4. Everything associated with collection that you can do from the GUI you can do from the command line (in fact the GUI calls the command line code to do the work).  

    Most of the checkboxes represnet values you pass to the /KernelEvents or /ClrEvents flags.   If you look in the help under these you are very likely to correclty guess which checkbox cooresponds to which flag.   You can actually confirm you guess by looking at the log where it shows you what flags were actually sent to the OS API.  

    There is a feature request to show the command line that the GUI options are equivalent to (thus you can just cut and paste it.    It is on the list, but don't hold your breath (there are many other features that come first…)

  5. Sean Hanna says:

    Thanks and great work.

    Any chance you are planning anything new for viewing ETW events using correlation / activity id's?

  6. Coorelating the causality between events on differen threads will be an area of ongoing inprovement.   ActivitityIDs will likely be a part of that, however, ActivityIDs don't magicially help, they are simply IDs (GUIDS) that ALLOW USER events to mark that they are releated, but is currently pretty error prone.  We are looking at what the way to do this in the least error prone way.   For example if you use the .NET TaskAPI  and/or the new .NET Async APIs, then stiching this cauality is pretty straightfoward and we already have some views that do this (Although arguably they are experimental at ths point, they have not existed long enough to be sure that they will be useful) .

    So the easy answer is: we are thinking about it (deeply), however it is early

  7. Sean Hanna says:

    (I tried to post a similar comment already but i'm not sure whether it actually got posted. You can moderate out one or the other if there are duplicates)

    When implementing my own ETW provider i found correlation to be under-documented, and so a little confusing to implement.

    My interpretation was that events were correlated using scopes. Event scopes are pushed / popped from the stack.

    When pushing a new scope do:

    1) set newActivityID = EventProvider.CreateActivityID()

    2) set oldActivityId = EventProvider.GetActivityID()

    3) call EventProvider.SetActivityID() with the newActivityId

    4) call EventProvider.WriteTransferEvent() with the oldactivityId for the related activity id

    when popping a scope do:

    1) call EventProvider.SetActivityID() with the oldActivityId

    2) call EventProvider.WriteTransferEvent() with the newActivityId for the related activity id ( i think this may be wrong)

    A clear example of how to do this (or a framework class) could make this much easier to implement without errors of course.

    In PerfView there doesn't seem to be any support for RelatedActivityID. Sorting on ActivityID (when using transfer events) is useless because nested scopes are put in completely different spots in the event stream. What i'd like is to be able to view the event in a hierarchy based on this scoping concept.

    There are probably some challenges to consider for building something like that though:

     1) perf view doesn't have a related activity id column

     2) only transfer events actually have a related activity id, so perf view would need to infer the related activity id for other events by finding transfer events with the same activity id's

     3) perf view either needs to be robust in how it handles these scoping behaviors or some guidance on the 'right way' needs to be published. I would be fine with either personally.

    The way i understood your comment, you weren't really discussing RelatedActivityID field at all, so maybe you could clarify a bit?

    Is there any good explanation of how the related activity id is intended to be used?

  8. For what it is worth, PerfView does happen to show RelatedActivityID in its event view, but as you indicate, the benefit of showing this field depends on everyone following a convention, which is the fundamental weakness of ActivityIDs (the error-prone-ness I refer to above).  I would LIKE our guidance to be 'Use Tasks' and you don't have to think about activity IDs at all, and PerfView does the work of stitching things together (since we can deduce everything from events that the CLR Task system generates).    This does not cover all cases however, which is why some thought is required.    

    What is clear, however, is that the fewer poeple who have to write code like the code above the better.  

    To answer your question, however is that I don't know of a good explaination of RelatedActivityIds to point you to.   Frankly you will get different answers depending on who you talk to.    I have my own thoughts on it, but generally I am trying to 'hide' them.   In particular, I would not bother with them unless on thread was causing an activity on another thread (if that happens on the same thread, the thread ID itself can 'relate' the two activities).   It is only things like 'threadpools' that need to bother.  

    As I mentioned, we are thinking about it…

  9. Todd Menier says:

    I have used DebugDiag with pretty good success for tracking down CPU spikes, memory leaks, etc in .NET code running in production. As PerfView and DebugDiag are both Microsoft tools with what seems to be a lot of overlap in functionality, I was wondering if you have any thoughts on how they differ or advice on when I might choose one over the other?

  10. I personally do not have any experience using DebugDiag, so I can't comment first hand.   From reading about it, however, it seems like the two tools do reasonably different things.   DebugDiag seems to be mostly about automating using the debug engine to gather information (thus I would assume it is reasonably snapshot oriented).   It also is more focused on diagnosing errors/hangs than on performance (leaks being the overlap).  PerfView is much more like a profiler, using ETW to collect information over time, (but it can take snapshots of GC heaps), and is much more about trying to display that performance data in a sensible way (but it does collect information on exceptions).  

    Given that you are already familiar with DebugDiag, I would certainly suggest that you continue to use that where it has served you well.   For you the real question is are there things that you would like to investigate that were not 'easy' in DebugDiag, that PerfView might be better at (e.g. I would expect PerfView to be better than DebugDiag at tracking down CPU problems, and frankly most 'Perf related' problems).  

  11. Bart Joy says:

    I sometimes run into unhandled exceptions in the application which result in a dialog box popping up and telling me "It should be reported so it can be fixed", but do not provide an email address or any other contact details. Where should I send the stack trace?

  12. Rich Deken says:

    Vance — I'm trying to track down a JavaScript leak using PerfView.  I'm choosing the option "Save JS ETL" but I don't see any additional ETL file with the JS data.  Am I doing something wrong?  Thx!

  13. What does the log say?    (if you re-open the GCDump file it will show you the log that was dumped at the time of collection).    It works when I tried it, here is the relevant snipit from the log.  

    *****  Attempting a ETW based JavaScript Heap Dump.

    SaveETL option specified, additionally saving the JS Heap as an ETL file.

    Starting Kernel Logging on App.kernel.etl

    Starting ETW logging on File App.etl

     0.0s: Enabling JScript Heap Provider

    In general JavaScript leak detection works much like .NET leak detection.  The only real difference is the names of the nodes.  

  14. Rich Deken says:

    I just looked at the log output and see the lines below:


    ***** Attempting a ETW based JavaScript Heap Dump.

    SaveETL option specified, additionally saving the JS Heap as an ETL file.

    JavaScript Heap Dumping only supported on Win8 or above.

    Wrote data to OUTLOOK.1.etl.


    We are running on Windows 7, Outlook 2010, and IE9.  Is there any way to get this to work under Windows 7?

  15. Sorry, you would need to run on WIn8 (it was assumed that the main scenario was Windows store apps, which of course need Win8).   Of course you just need a Win8 machine /VM to run the experiment on.

Comments are closed.

Skip to main content