Measuring startup performance when using .NET Native Developer Preview

I got really excited about .NET Native technology last week when I first heard about it during Build. I wanted to measure performance in my Windows Store apps to see how it can improve it (especially startup times!), and in order to do that I was going to user EventSource and PerfView. Unfortunately, something didn't work, but the team helped me go around it!

.NET Native is a new (cloud) compiler technology from Microsoft which, in essence, makes it simple to write apps using C# (which we love and we're really productive in it, right?) with C++ performance. It's in a public developer preview phase, and currently enables compiling Windows Store apps written in C# for x64 and ARM architectures. The team did a lot of things to make that possible, so in order to get up to speed, here are the most important links about it that you can check out:

Announcing .NET Native Preview

Debugging support for .NET Native Preview apps

MSDN .NET Native homepage (contains download links etc.)

Inside .NET Native (Channel 9 video)

.NET Native FAQ

Optimizing .NET for Modern Hardware (Build 2014 video)

Compiling Apps with .NET Native (MSDN detailed implementation documentation)

The last link contains info on how to measure startup and performance improvements with .NET Native. So that's what I wanted to do, but I got stuck!

EventSource and .NET Native

The suggested method of measuring startup performance is to emit events using EventSource in both managed and native environment and then compare the results. Long story short, there seems to be a bug in .NET Native preventing that implementation from working when you actually compile with .NET Native (but it works great using standard compiler) so you can't compare anything really. And this phase is all about measuring performance improvements!

What's amazing here is the response from the team in this Developer Preview phase. They're looking for feedback and helped me get around this bug!

Quick solution

The response from the team member Xy Ziemba was essentially this:

There’s an issue that prevents events that don’t have event arguments from being emitted...
The workaround is to just add a dummy argument to the event. Just use one of the other overloads of WriteEvent to do this.
I have filed the bug for this internally and I expect it to be fixed in the next release of .NET Native. We’ll also update the documentation in the interim.

So, in order to get around this bug, just use a class like this one:

public sealed class AppEventSource : EventSource  
    public static AppEventSource Log = new AppEventSource();

    public void AppInitialized() { WriteEvent(1, ""); }

    public void MainPageInitialized() { WriteEvent(2, ""); }

Notice the empty string as WriteEvent argument! If you notice any issues or bugs, give feedback to the team! They are really quick to get back. I'm really excited to see what they do next!

About Igor Ralic

Software engineer at Microsoft. Running for Office. Passionate about making an impact with great apps & services. Stays close to coffee and away from coriander. Opinions expressed here are my own.