Vance Morrison

Vance Morrison Vancem Vance Morrison

Niner since 2012

Vance Morrison is the Performance Architect for the .NET Runtime at Microsoft.  He spends his time either making various aspects of the runtime faster or teaching other how to avoid performance  pitfalls using .NET.   He has been a involved in designs of components of the .NET runtime since its inception.  Previously he drove the design of the .NET Intermediate Language (IL) and has been the Development lead for the just in time compiler for the runtime.



  • Defrag Tools #118 - PerfView Part 6

    @androidi: ETW is not heavy weight necessarily, but if you ask it to do a lot it will use the hard drive a lot.    In particular if you want stack traces, it does do what is called 'merging' which involves finding all the DLLs that were in the trace and getting the PDB signatures (so you can find the PDBS) from the DLLs.   This does take 10s of sec and uses the hard drive.    However if you collect just a little, then it is very light.   This is independent of OS version. 

    @PerfectPhase: Your situation is complicated by the fact that you seem to wish your output to go to the windows event log (using channel attribute).   This mechanism is 'old style' where a eventSource 'knows' where it is logging (a particular place (channel) in the windows event log).   As you can see for complex situations, it is not as flexible as you would wish.   Your situation however is complex enough that it does not make sense to discuss it in the comments.  If you still care you can contact me at and I can describe other options you have.  

    @Onurg: I don't properly understand your complaint, but something I did not talk about in the video is that EventSource can go to in-proc event listeners.   Thus if you REALLY like the way log4Net works, you can frankly pipe all the data from your eventSource to whatever logging mechanism you would like to use.   The advantage of this is that you can go to BOTH log4Net AND ETW (and frankly anywhere else), and code that does the logging does NOT KNOW what logging mechanism is used (thus you get dependency injection for 'free').    

    @MagicAndre1981: For what it is worth, the fact that stacks interfere with evnetSource decoding is a known bug in the WPA stack.   They are working on a fix.   You can use PerfView to work-around the problem in the short term.   They should have a fix reasonably soon.  

  • Defrag Tools #116 - PerfView Part 4

    @philipecp:  To make PerfView find your own source code you simply need tell PerfView where to find the PDBs and the root of the source code.   You can do this with the _NT_SYMBOL_PATH and _NT_SOURCE_PATH that you may be familiar with, but you can also add these paths using the GUI in the 'set Symbol path' and 'set source path' menu entries in the stack view (PerfView remembers these options from one invocation to the next).   To make it work with the TFS you need to follow the instructions with setting up a source server (out of scope).  

    @vlad: Unfortunately the operating system does not raise any events when the 'RaiseException' or C++ exceptions are raised.    You can however do this yourself in your own code by using ETW APIs, but that is extra work.   


  • Defrag Tools #113 - PerfView Part 1

    @MagicAndre1981: For what it is worth, While the default is designed to get the common case, PerfView gives you easy, complete control.   In particular

    PerfView /kernelEvent=none /clrEvents=none /providers=YOUR_PROVIDERS collect

    Will only enable YOUR_PROVIDERS.  There is a shortcut for that

    PerfView /onlyProviders=YOUR_PROVIDERS

    However the first form is nicer if you do want some of the kernel events or CLR events.   The later form is great if you just want to turn on your specific EventSource.  

  • PerfView Tutorial 1 - Collecting data with the Run command

    There are high quality video links just to the right of the right that you can click on (I mention that in the text below the video frame).  I recommend the WMV version (it is the original).  

    To answer MagicAndre1981's question, I am a big fan of XPerf/WPA, and work with that team to make it better.   If you are happy with WPA, certainly stick with it, it is a very powerful tool.   I like to believe that most of the knowledge you learn in using one tool is applicable to the other.  

    As to why we have both, the simple answer is that XPerf had a codebase (originally completely unmanaged), and and a installed-base / client base  (the OS guys), that make it evolve in a certain direction and at a certain rate.    Historically it did not suppport managed code well, and adding extensions is harder than you would like.    Originally the goal was simply to have a managed code interface to ETW data.    However once you have this, you start wanting to explore better/different ways of presenting the data, which is the genesis of PerfView.  

    For what it is worth...

  • PerfView Tutorial 1 - Collecting data with the Run command

    Yes, I actually just now noticed that.   In fact the C9 team did get a hold of me back in January.  The delay is all my doing.    The last several months has been a big push for us to get Win8 ready, and only now are things calming down.    Anyway better late than never...