PerfView Videos

The documentation built into PerfView is intended to be sufficient to tell you what you need to know in order to use the tool effectively. However it is still valuable to have someone actually demonstrate the tool in action. Here we present a set of tutorial videos that will present the basics.

Each tutorial is designed to be short and cover only one topic. This allows you to pick and choose the topics of interest and skip what is not currently relevant easily. Also keep in mind the Ctrl-Shift-G (go faster) and Ctrl-Shift-N (Normal speed) feature of Windows Media player. This can help you watch the videos even faster. 

Getting the Latest PerfView Videos

The videos listed below are those that existed at the time this version of PerfView was released.   Since more videos are being added all the time, you should check the PerfView Tutorial Series for the latest additions. 

Getting PerfView

  1. Getting PerfView from the Internet -(2 min) - PerfView is REALLY easy to get. If you have an internet connection you are about 4 clicks away from running perfView. This QUICK video shows you how.

Time Investigations

The most common kind of performance investigation is optimizing time. For this case, the PerfView has the 'Run' and 'Collect' command that will generate ETL (event trace log) files that are used for analysis.

Collecting Data for Investigations into Time

  1. Collecting Data with the PerfView 'Run' Command -(5 min) - Before you can investigate, you first have to collect. If your scenario can be run from the command line easily, you shoud use the 'Collect -> Run' command to collect the data. You can be finished collecting in less than a minute.
  2. Collecting Data For Services -(7 min) - When investigating services it is convinient to explicitly start and stop the trace. It is also very common to want to collect data on one machine (often by asking someone else to collect the data) and then analyze it on another machine. This video shows you some of your options for server-scenario data collection.

CPU Investigations. 

The most common kind of Time investigation is investigating high CPU usage

  1. A Simple CPU Investigation (16 min) - Typically the first investigation you do is to check on CPU usage. This totorial is longer than most, but that is because it covers a lot of important 'background' information need to be a productive investigator. If you watch only one video, this should be it.
  2. Symbol Resolution (5 min) - By default Perfview only resolves 'easy' symbols (which include many managed methods). If you need symbol (.pdb) files to resolve addresses to names you typically need to ask PerfView to do this explicitly. This video shows you what the process is where PerfView looks by default, and where to start if you have problems getting symbols.
  3. Grouping And Folding (13 min) - Something that sets PerfView apart from most other profiling tools is its ability to hide a large amount of irrelevant detail while also allowing you to have high detail on the parts of the application that matter to you.   This magic is done by the grouping and folding features (GroupPats and Fold* textboxes).   This video talks demonstrates this power and gives you the basics you need in order to use it effectively.  
  4. Drilling Into Cost (6 min) - In the first phase of an investigation you use the grouping and folding features to reduce the number of nodes you are considering.  Your goal is to create nodes that are 'sematically meaninful' which account for a substantial part of the cost.  After this grouping is complete, you know what to look at, the question is 'How?'.   If you were to ungroup, the problem is that are effectively undoing the work you just did.   Instead you want pick the samples from JUST ONE ENTRY, and 'Drill into' those.  Once these samples are in their own window, you can safely ungroup without unrelated calls that you are not interested in skewing the statistics.   This view shows you how easy it is to do this.

Wall Clock Time Investigations. 

Typically if you aredoing a time investigation, you are concerned about wall clock time (not CPU time).   Thus you can argue that wall clock time investigations are more important that CPU investigations.  However wall clock time is more harder to investigate because every thread in your process has its own wall clock time, and what you are intersted in is the CRITICAL PATH among these threads.   CPU is nice because it TENDS to be on the critical path (even if the flow of control hops from thread to thread), which means ANY CPU time is probably important.  This is NOT true for wall clock time and is part of what makes it harder to analyze.    These videos walk you through what you need to know in order to do a successful wall clock time investigation. 

  1. Wall Clock Time Investigation Basics (16 min) - This video walks through a wall clock investigation on a very simple scenario (a disk bound sequential program).   It covers how you should collect the data (the Thread Time checkbox), as well as using a method frame to isolate time to a particular thread and time interval for analysis.
  2. Leveraging Tasks make sense of Parallel/Asynchronous programs (16 min) - This video walks through a more complex scenario where operations are happening in parallel and shows you that if you used System.Diagnostics.Threading.Tasks to do the parallel activity, PerfView can 'roll up' the costs of the paralllel/async activity in a way that allows parallel/async programs to be analyzed like the simpler sequential case.
  3. Investigating Wall Clock Response Time of ASP.NET scenarios (16 min) In this video we show how to analyze the wall clock response time of an ASP.NET application.  I also discuss this scenario in this blog entry.

The PerfView Event Viewer

Fundamentally an ETW data file is a time order list of events.   Some of the views (like the 'CPU Stacks' view) will regroup these events based on the stack traces that are attached to events, but by necessity these views throw away much of the data in that was logged with the event.   Thus there are times when you want to see the 'raw' view, where you see a time ordered list of events where each event can have a particular event-specific payload.   This is what the EventViewer is shows you.  

  1. Event Viewer Basics (16 min)  - Using the data in the tutorial example, we describe the basic funtionality of the Event Viewer, which is mostly about filtering events (by name, time, process, and text) as well as deciding which fields to display.    Also shown are features for accessing the stacks associated with particular events and the ability to export the view as a CSV (Excel file) for further processing.
  2. The Event Viewer in ASP.NET Scenarios (6 min) - ASP.NET is a common sceanrio for many server workloads, and ASP.NET can log ETW events that are very helpful in isolating the processing of one request from all the other processing that is happening on the server.   In this video we demonstrate how to use these events to help in an investigation. 

Using System.Diagnostics.Tracing.EventSource to Log Your Own Events

When doing any time based investigation, it is very useful to know what the program is doing at a 'high level', so that you can easily zoom into these logical regions and focus on just certain aspects of your applications performance.   This is especially important in server scenarios as well any scnearios that use asynchronous I/O (because Async I/O makes it harder to use the stack of your program to do the same thing).    There is a class in Version 4.5 of the .NET Framework called System.Diagnostics.Tracing.EventSource that lets you do just this.  Using this class it is trivial to make your .NET program log ETW events with whatever payload you desire.   These videos show you how.

  1. Generating Your own Events with EventSource (12 min).  This video is an introduction to using EventSource, showing you how to write the code, how to turn on your event source and how to view the resulting log messages in the PerfView Event Viewer (see Event Viewer Basics above).    There is also a companion blog entry that has links to a version of EventSource that works on versions of the .NET Framework before V4.5. 

Memory Investigations

PerfView's capabilities break into two rough categories, time (based on ETW events), and memory (based on memory snapshots).   In this section we go into detail on how to use PerfView to do a Memory Performance investigation. 

  1.  Basics of GC Heap Snapshots (9 min) - The first step in doing  .NET Memory investigation is first determine whether .NET Memory is your problem and take a heap snapshot.   This tutorial shows you how to determine how much of your process's memory is GC heap and (if that is your problem) shows you how to take a snapshot of the GC heap. 
  2. Investigating .NET Heap Memory Leaks: Part 1: Collecting the Data (8 min) This is the first of a two part video of step-by-step instructions for using PerfView to investigate a 'Leak' in the .NET GC heap.  This first part goes through the mechanics of collecting the data which involves taking two heap snapshots at appropriate times. 
  3. Investigation .NET Heap Memory Leaks: Part 2: Analyzing the Data (11 min).  In this second part we take the two snapshots collected in part 1 and walk though the mechanics of doing a 'diff' of the two memory heaps to determine how the heap grew between the two points in time.  This lets us home in on places where we were not dropping references to objects (which caused them to 'leak').