<commit_before>---
title: "Using the Windows Performance Toolkit to analyze performance marks on Edge and Chrome"
cover: /img/wpa-marks/filter-to-marks.png
isPost: true
active: true
excerpt: Learn how to use the Windows Performance Toolkit to drill into web app scenarios using performance.mark
postDate: '2017-07-24 11:53:27 GMT-0700'
tags:
 - performance
 - chrome
 - edge
 - wpa
---

I have a bit of a love / hate relationship with the [Windows Performance Toolkit][wpt]. It's easy to be overwhelmed by
it, and it can be a bear to use sometimes, but there's very few tools as powerful when it comes to understanding
performance, and it's hands down the best tool on Windows for doing apples-to-apples comparisons of browser performance.

## What is WPA?

The part of the Windows Performance Toolkit that we're instersted in is the Windows Performance Recorder (WPR) and the
Windows Performance Analyzer (WPA). There's extensive information on using both like [this][todd-wpt], [this][tobin-wpt],
[this][msdn-perf], and [this][msdn-memory], so rather than write a below average tutorial, I'll defer to those fine resources.
Just know that Event Tracing for Windows (ETW), the underlying technology, provides a low overhead, full system view of
performance.

## What are performance marks and measures?

`performance.mark()` and `performance.measure()` are both part of the [User Timing spec][user-timing-spec]. It's
[well supported][caniuse], with only mobile Safari and Opera Mini lacking support, and excellent polyfills like Nolan Lawson's
excellent [Marky][marky] are available.

These APIs allow a web developer to add "points of interest", such as when a component renders, or when background events
start and stop, to the [UI responsiveness tool][f12-responsiveness] in your browser's developer tools. You can also collect
your users' marks using your site analytics to better understand how your components behave in the real-world, but we'll save
that for another post.

## Viewing Edge's marks in WPA

Capturing marks from Edge couldn't be simpler, just:

1. Ensure you [record your trace][todd-wpt] using the **Edge Browser** scenario
2. Run your scenario which uses the `performance.mark()` API
3. Save your trace

That's really it!

To view the marks, load up the trace and add the **Generic Events** graph, which is under the **System Activity** section.
Each mark will be an event under the **Microsoft-IE** provider, and the **Mshtml_MsPerformance_Mark** Task Name. The name
your app supplied for the event is available in **Name** field, which is also **Field 1** (ETW providers can label the
event's payload fields).

![Viewing Edge performance marks in WPA][wpa-marks-edge]

## Viewing Chrome's marks in WPA

There's a bit more effort involved in getting Chrome to emit ETW events, but thanks to <NAME> (who's
[blog][randomascii] you should definitely be reading!) and the [UIforETW][uiforetw] project, we have all the information
we need.

### Registering Chrome's ETW provider

First we need to register Chrome's ETW provider. Registration tells the ETW system how to "subscribe" to Chrome's events
and how to decode the binary payload into fields. To register:

1. Download `DummyChrome.dll` and `chrome_events_win.man` from https://github.com/google/UIforETW/blob/master/bin/
2. Unregister and reregister (so that any changes take effect) Chrome's ETW event provider and manifests using `wevtutil` from an _elevated_ command prompt

```cmd
wevtutil uninstall-manifest C:\full\path\to\chrome_events_win.man
wevtutil install-manifest C:\full\path\to\chrome_events_win.man /resourceFilePath:C:\full\path\to\DummyChrome.dll /messageFilePath:C:\full\path\to\DummyChrome.dll
```

> NOTE: Replace `C:\full\path\to\` as necessary. `wevtutil` requires an _absolute_ path.

> NOTE: `wevtutil` may give a warning similar to `**** Warning: Publisher Chrome resources could not be found or are not accessible`. This warning is safe to ignore.

3. Finally, in order for Chrome to actually _emit_ events, we need to tell Chrome to enable ETW tracing. That's as simple
as passing flag `--trace-export-events-to-etw` when starting Chrome

```cmd
call "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --trace-export-events-to-etw
```

> NOTE: You may need to close existing instances of Chrome before passing this flag to ensure you get the correct behavior.

### Using a Chrome WPR Recording Profile

Now that Chrome is all set up to emit ETW events, we need to set up WPR to subscribe to those events. The easiest way to
do that is:

1. Save this XML file as a .wprp (Windows Performance Recorder Profile) file.

```xml<commit_msg>Update using-wpa-to-analyze-performance-marks.html.md (#1)<commit_after>---
title: "Using the Windows Performance Toolkit to analyze performance marks on Edge and Chrome"
cover: /img/wpa-marks/filter-to-marks.png
isPost: true
active: true
excerpt: Learn how to use the Windows Performance Toolkit to drill into web app scenarios using performance.mark
postDate: '2017-07-24 11:53:27 GMT-0700'
tags:
 - performance
 - chrome
 - edge
 - wpa
---

I have a bit of a love / hate relationship with the [Windows Performance Toolkit][wpt]. It's easy to be overwhelmed by
it, and it can be a bear to use sometimes, but there's very few tools as powerful when it comes to understanding
performance, and it's hands down the best tool on Windows for doing apples-to-apples comparisons of browser performance.

## What is WPA?

The part of the Windows Performance Toolkit that we're instersted in is the Windows Performance Recorder (WPR) and the
Windows Performance Analyzer (WPA). There's extensive information on using both like [this][todd-wpt], [this][tobin-wpt],
[this][msdn-perf], and [this][msdn-memory], so rather than write a below average tutorial, I'll defer to those fine resources.
Just know that Event Tracing for Windows (ETW), the underlying technology, provides a low overhead, full system view of
performance.

## What are performance marks and measures?

`performance.mark()` and `performance.measure()` are both part of the [User Timing spec][user-timing-spec]. It's
[well supported][caniuse], with only mobile Safari and Opera Mini lacking support, and excellent polyfills like Nolan Lawson's
excellent [Marky][marky] are available.

These APIs allow a web developer to add "points of interest", such as when a component renders, or when background events
start and stop, to the [UI responsiveness tool][f12-responsiveness] in your browser's developer tools. You can also collect
your users' marks using your site analytics to better understand how your components behave in the real-world, but we'll save
that for another post.

## Viewing Edge's marks in WPA

Capturing marks from Edge couldn't be simpler, just:

1. Ensure you [record your trace][todd-wpt] using the **Edge Browser** scenario
2. Run your scenario which uses the `performance.mark()` API
3. Save your trace

That's really it!

To view the marks, load up the trace and add the **Generic Events** graph, which is under the **System Activity** section.
Each mark will be an event under the **Microsoft-IE** provider, and the **Mshtml_MsPerformance_Mark** Task Name. The name
your app supplied for the event is available in **Name** field, which is also **Field 1** (ETW providers can label the
event's payload fields).

![Viewing Edge performance marks in WPA][wpa-marks-edge]

## Viewing Chrome's marks in WPA

There's a bit more effort involved in getting Chrome to emit ETW events, but thanks to <NAME> (who's
[blog][randomascii] you should definitely be reading!) and the [UIforETW][uiforetw] project, we have all the information
we need.

### Registering Chrome's ETW provider

First we need to register Chrome's ETW provider. Registration tells the ETW system how to "subscribe" to Chrome's events
and how to decode the binary payload into fields. To register:

1. Download `DummyChrome.dll` and `chrome_events_win.man` from https://github.com/google/UIforETW/blob/master/bin/
2. Unregister and reregister (so that any changes take effect) Chrome's ETW event provider and manifests using `wevtutil` from an _elevated_ command prompt

```cmd
wevtutil uninstall-manifest C:\full\path\to\chrome_events_win.man
wevtutil install-manifest C:\full\path\to\chrome_events_win.man /resourceFilePath:C:\full\path\to\DummyChrome.dll /messageFilePath:C:\full\path\to\DummyChrome.dll
```

> NOTE: Replace `C:\full\path\to\` as necessary. `wevtutil` requires an _absolute_ path.

> NOTE: `wevtutil` may give a warning similar to `**** Warning: Publisher Chrome resources could not be found or are not accessible`. This warning is safe to ignore.

3. Finally, in order for Chrome to actually _emit_ events, we need to tell Chrome to enable ETW tracing. That's as simple
as passing flag `--trace-export-events-to-etw` when starting Chrome

```cmd
call "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --trace-export-events-to-etw
```

> NOTE: You may need to close existing instances of Chrome before passing this flag to ensure you get the correct behavior.
> NOTE: Make sure to start Chrome from a regular Command line instance and not from an Administrator Command Line. The higher priveleges used in the admin command line can at times mess with the execution of Chrome.

### Using a Chrome WPR Recording Profile

Now that Chrome is all set up to emit ETW events, we need to set up WPR to subscribe to those events. The easiest way to
do that is:

1. Save this XML file as a .wprp (Windows Performance Recorder Profile) file.

```xml
{'fraction_non_alphanumeric': 0.08132120832026758, 'fraction_numerical': 0.006376084456987561, 'mean_word_length': 4.6884661117717, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 12, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4669334', 'n_tokens_mistral': 2741, 'n_tokens_neox': 2580, 'n_words': 1320}