 Hi, my name is Hari Krishna Mainan and I'm a Program Manager in the Visual Studio team. Performance is a critical aspect of any application. Customers expect applications to load fast, as well as interactions with them to be jitter-free and fluid. The application timeline tool helps you improve the performance of your WPF applications by providing a semantically rich, scenario-centric view of your application's resource consumption. You can analyze the time spent by your application, preparing UI frames, servicing network and disk requests, and much more in the context of scenarios like application startup and page load. This tool is available for Windows Store, Windows Phone, WPF, and UAP platforms. In this video, let's take a quick look at the capabilities of the application timeline tool in Visual Studio 2015. I have here a simple stock ticker application that shows the value of shares for a specified set of stocks over the last one year. Right off the bat, you can notice that the startup is super slow, and I'm going to use the new application timeline tool to figure out what could be wrong in my application. I'm going to close this app, switch back to Visual Studio, and open the Performance and Diagnostics Hub. I can do that by going to the Debug menu and clicking on Start Diagnostic Tools Without Debugging. This opens up the Performance and Diagnostics Hub in Visual Studio. You can see the new application timeline tool and the CPU usage tool is already selected. I'm going to now launch the application under the profiler. The application is launched and if I switch back to VS, you can see that a live CPU utilization graph is shown that shows the amount of CPU that's being consumed by your application. It looks like the application is completed loading. I'm going to switch back to VS and hit Stop Collection. As Collection might take some time, I'm going to switch back to my pre-prepared session file. When the session report comes up, you can see that we show you three graphs. The first graph is a UI thread utilization graph. The UI thread utilization breaks down the utilization of your UI thread into its components that is understandable to users. For example, we tell you the time taken by parsing, layout, render, IO, and application code. You can see that there is a lot of application code running during application startup. The second graph is the visual throughput graph. It tells you the frame rate of your application in the desktop window manager in the composition thread and on the UI thread. You can see the frame rate was pretty much zero for the UI thread during application startup. That means it was completely busy. Now let's take a look at the details view. In the details view, you can see we have created a top-level event called application startup. This event measures the time between the application is launched by the operating system and the time taken for your application to show its first frame. So this is super interesting. So I'm going to right-click on this event and do filtered event time range. When I do that, my view is filtered by the time taken for application startup and I can view all the events that happen during startup. I can see my application spend 170 milliseconds in parsing. When I open that, it shows me all the files that were parsed as a result of parsing app.zaml. The parsing cost is inclusive of the time taken to parse the file and the time taken to create the object. It also shows me layout cost of each individual element. It tells me what the cost was for each element to layout during the layout pass. This is very interesting since it'll help me troubleshoot complex custom panels and their logic if they take too much time during layout. We also support a number of filters and sort functions to make it easier for you to slice and dice your data. We also allow you to group by frames and there are a number of search functionalities available as well. Now let's take a look at the CPU usage tool since none of these events can explain why it took so much time for my application startup. I'm going to shift to the CPU usage tool and you can see that the main is taking almost 95% of the time. I'm going to keep drilling down to see which function is responsible for this. And here I can see that model.getData is a function that's responsible for spending so much time on the CPU during application startup. Let me take a look at that code. This getData function looks like it's doing a lot of computation and network requests on the UI thread. And let's see how much time this is taking. I'm going to put a breakpoint at the start of the function and I'm going to put a breakpoint at the end of the function. Now I'm going to start debugging. You can see that the first breakpoint gets hit. Now I'm going to continue execution. As you can see, it's taking quite a lot of time to execute this function. And you can see here the new feature called perf tips tells me the time taken between these two breakpoints and it's a good eight seconds, which is not that great. But I know I can quickly fix this by running all this logic on a different thread. So I'm going to stop debugging, go to my toolbox. I already have a snippet created to optimize this function. I'm going to delete this and drag my snippet over here. And you can see that it's pretty easy for me to run this code on a separate thread. Now I can use my profiling tool to measure the new startup of my application. Let me open up the performance and diagnostics hub again. I'm going to use the same tools and launch a profiling session. With the change that I made before. Since collection and profiling takes quite some time, I'm going to switch back to VS and go to my preprepared optimized session file. You can see that there is no longer any application code running on the UI thread, on the UI thread utilization graph. And the application startup has been reduced from 10 seconds to 1.5 seconds, which is a significant improvement. This is how you can use the new diagnostic experiences in Visual Studio to successfully troubleshoot your XAML applications. I would like to thank you for taking the time today to learn about the new application timeline tool. The Visual Studio and WPFT blog has more details around the features of this tool. You should download Visual Studio 2015 today and try out the new application timeline tool and other new diagnostic experiences in Visual Studio 2015.