Windows lets you give names to the threads in your process which can then be displayed by debuggers. This is a great idea, but the implementation is showing its age – it’s time for some fixes, or something better.
Over the last few years I’ve written over forty blog posts that discuss ETW/xperf profiling. I’ve done this because it’s one of the best profilers I’ve ever used, and it’s been woefully undersold and under documented by Microsoft. My goal has been to let people know about this tool, make it easier for developers and users to record ETW traces, and to make it as easy as possible for developers to analyze ETW traces.
Some of those posts have aged poorly, and the rest are hidden amongst the 160+ posts (really? wow) I’ve written. The purpose of this page is to be a central hub that links to the ETW/xperf posts that are still relevant. Also, I’ve updated many of the older posts to reflect changes in the ETW toolset (technically known as the Windows Performance Toolkit). For convenience this page is accessible as https://tinyurl.com/etwcentral.
If your Windows computer is running slowly – if a program takes a long time to launch, if a game has a poor frame rate, or if an idle application uses too much CPU time – the best way to investigate is to record an Event Tracing for Windows (ETW) trace. An ETW trace records a wealth of information (CPU sampling, context switches, disk I/O, custom data, and much more) that allows most performance problems to be understood by a trained expert. If you’re not a trained expert then you can still record an ETW trace, and then share it with somebody who is.
If a particular program is being slow or inefficient then you may be able to record an ETW trace and share it with the authors of that program. Quite often they can figure out what is going wrong, whether it is a bug on their side or an overheating CPU on your side. Tell them I sent you. They may be grateful for receiving an actionable report instead of vague complaints about slowness which they cannot reproduce.
Not all developers are equipped to analyze ETW traces, for technical and practical reasons – ask first.
A new version of Windows means a new version of the Windows Performance Toolkit (WPT), the ship vehicle for xperf, WPA and other Event Tracing for Windows (ETW) tools.
I’m a huge fan of xperf/ETW (just look at some of the performance investigations I’ve done with it) and the new version offers enough improvements that I’m switching to WPT 10 immediately, but keeping WPT 8.1 installed, with UIforETW automatically selecting between them. You should too.
Event Tracing for Windows (ETW) has always recorded a rich set of data and allowed graphing it all on the same timeline. With the creation of UIforETW (which records more data) and the new* ETW trace viewer (which can graph custom data) the ability to visualize important patterns is better than ever before.
And, what better way to visualize how to create graphs than a video demonstrating what is discussed in this post.
When I’m describing what I do for a living to non-programmers I sometimes say that I solve puzzles. I solve fascinating puzzles that are different every day, and there’s no answer key, and very often nobody else knows the solution. Whether it’s figuring out why code is slow, or why it is crashing, or how to make code simpler and better, it’s all puzzles, and I love it.
Event Tracing for Windows (ETW, aka xperf) is usually used to monitor CPU usage, through its sampling profiler and its ability to record detailed information about context switches. Well, ETW is also used to monitor file I/O, and disk I/O, and sometimes registry accesses, and of course GPU activity, window-in-focus, UI Delays, process lifetimes, and a few other things. Okay, so ETW gets used for a lot of different things, normally configured in the same way and recorded across the entire system.
Heap profiling is different. Even to those who are used to the odd incantations needed to record an ETW trace it can be daunting trying to figure out how to do heap profiling. I’ve postponed writing about it because it was too much work to explain how to record heap traces and analyze them. But now that UIforETW has been released it is almost trivial to record ETW heap traces, and even analyzing them is made easier.
And, as a bonus, system memory-lists and VirtualAlloc calls for all processes are recorded in all UIforETW traces and lightly documented at the bottom of this post, with optional VirtualAlloc call stacks for lightweight memory profiling.