My diary of software development

Posts tagged ‘Windows Store’

Performance Diagnostics for Windows Store Apps in Visual Studio 2013

Pillars of Performance

Microsoft has identified three pillars of performance which ground the perceptions of Windows Store (WS) Applications. These perceptions include such effects as responsiveness, battery usage, and others which trigger bad reviews of a WS application.

Line of Business (LOB) applications will not be purchased from the app store and therefore do not depend on reviews for monetization, however these Pillars of Performance are still vital to an LOB application.

Fast

A WS Application should be snappy when moving from one view to the next. In addition all elements must remain responsive during a heavy back end operation.

In addition to creating snappy single operations, we must also consider a composite operation of back end work as well as UI animations and view changes. A lot of the costs incurred during a composite operation are incurred by the UI framework on our behalf.

Fluid

This pillar describes how ‘buttery smooth’ the UI is during panning, scrolling, or animation. For example scrolling horizontally across data groups on the view or the animation which may show detailed information about a specific data group.

Efficient

This pillar signifies how well the app plays with other apps in the Win8.1 sandbox. For example, if a WS Application has a large amount of memory leaks, or unnecessary disk read/write activity then it will consume more battery energy than it needs. This will force the user to stop their work and recharge the battery.

Managed Memory Analysis

Visual Studio 2013 allows us to perform analysis on managed memory in our WS Applications. If we go back and review the 3 Pillars of Performance we see that managing memory and cleaning up leaks affects the two Pillars of Application Speediness and Efficiency.

For example we may see a page coming up slowly because it is storing a large object graph into memory. In this case we’ll use the Managed Memory Analysis results to detect this large object graph storage and may be able to work around the need to store that much data into memory.

In order to perform the Managed Memory Analysis you will also need the SysInternals tool ProcDump.

Batch File Utility

In addition to Visual Studio 2013 and the ProcDump tool there is another tool (a batch file) which is not required but will make the process of dumping and opening the analyses easier. Prior to running the batch file you should start the application and get it to the state where you want to perform the analysis. You can start the target app through the Start Menu or through Visual Studio (without debugging – Ctrl+F5.

   1:  set ProcDump=SysInternals\ProcDump
   2:   
   3:  set ProcName=App2.exe
   4:   
   5:  %ProcDump% -ma -o %ProcName% BASELINE.DMP
   6:   
   7:   
   8:  @echo ============================================================
   9:  @echo ============================================================
  10:  @echo ============================================================
  11:  @echo The baseline dump file has been written.
  12:  @echo Exercise your app and when you are ready for the next dump,
  13:   
  14:  @pause
  15:   
  16:  %ProcDump% -ma -o %ProcName% FINAL.DMP
  17:   
  18:   
  19:  @echo ============================================================
  20:  @echo ============================================================
  21:  @echo ============================================================
  22:  @echo Your dump files have been completed:
  23:  @dir *.dmp
  24:   
  25:  @FINAL.DMP

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

 

abc

Batch File Line Numbers

1. Sets the variable named ProcDump to the full path of the ProcDump utility

3. Sets the variable named ProcName to the name of the application you wish analyze. This is the name which appears in Task Manager when the application is running.

5. Creates the baseline memory dump of the application. This dump file will be named BASELINE.DMP and be stored in the same folder as the batch file.

14. This line pauses the script which allows us to run the application through the states we wish to analyze before taking the final memory dump.

16. This line is executed after the pause and creates the final dump file named FINAL.DMP. It will also be stored in the same folder as the batch file.

25. This last line will cause Visual Studio to be launched and open the final dump file. You will then see a summary of the dump file as shown below:

Pic1

Execute the Memory Analysis

  1. Click the Action link named ‘Debug Managed Memory’ on the right and you will be presented with this screen:
  2. pic2
  3. At the top right of the screen click the Select Baseline drop down. Then browse and choose the BASELINE.DMP file. Your next screen will show results for the analysis between the FINAL.DMP and the BASELINE.DMP memory dumps.

Tracking down a Memory Leak

In order to demonstrate the act of tracking down a memory leak we’ll use a simple application that allows the user to transfer back and forth from Page 1 to Page 2 with the click of a button:

pic3 pic4

When Page 2 comes up, it creates a large number of objects and never deletes them.

After starting the app we must run the batch file to create the BASELINE.DMP file. When the batch script pauses we will switch between the app pages a few times and then have the batch script create the FINAL.DMP file.

Once Visual Studio performs the analysis we will see the view showing the difference between the BASELINE.DMP and the FINAL.DMP memory dumps. This view has several columns in it and they are described next.

pic5

 

Object Type Column

The type of object for the line. Instances of this type may or may not have been leaked.

Count Column

The number of instances for this type that were left when we took the FINAL.DMP dump file. This number does not indicate a leak if it is greater than zero.

Total Size Column

The total size of the instances which were left when we took the FINAL.DMP dump file. Again, this number does not indicate a leak if it is greater than zero.

Count Diff Column

The difference between the number of instances in the BASELINE.DMP and the FINAL.DMP dump files. This number does indicate a leak if it is greater than zero.

Total Size Diff.

This number represents the size of all of the instances represented by the Count Diff Column. This number does represent a leak if it is greater than zero.

We see there are a lot of objects showing that are in the System namespace and we want to filter our results to just those objects in our application’s namespace. We can do this by typing App2 in the upper left Search box.

pic6

We can then immediately see there are 1,500 instances of the Order class which have been leaked.

If we expand the App2.Order object type, we see the 10 largest instances. Then if we select one of those instances we’ll see it is referenced by an of Order[] which is referenced by a List<Order> which is finally referenced by an Object[].

We should then look in our application’s codebase to find where Order instances are created and why they’re not being cleaned up.

Energy Consumption

Visual Studio 2013 has a new diagnostics tool which provides Energy Consumption metrics for a WS Application. To run the tool, open a WS application and press Ctrl+Alt+F9 or go to the Debug menu and choose Performance and Diagnostics.

You will be presented with the dialog shown below where you should check ‘Energy Consumption’ and press Start.

pic7

In our example, we will run a WS Application under the Energy Consumption tool and perform some operations within the application. After doing so, we will go back to VS where we will see this screen:

pic8

Timeline Graph

Press the ‘Stop Collection’ link to stop the diagnostics run and build a report. After a few seconds you’ll see a timeline graph at the top representing energy consumption over time.

pic9

This report provides power usage metrics for four items:

1. CPU

2. Display

3. Network

4. The Total of the above 3.

Display Usage

The display metrics normally stay constant during the run however in the Timeline Chart at the top, the display usage drops to zero between 5s and 12s. This is the result of a problems in the WS Application which was tested. Therefore the display usage during this time slot can be disregarded.

Some things which affect display usage are:

· Display size

· Screen brightness

· Display technology

CPU Usage

In the timeline graph of the energy usage by the CPU, we see several spikes between 1s and 5s. This is when the application is starting.

We’ll see another spike between 7s and 10s but again, we can ignore this metric change as it takes place during this particular application’s misbehavior.

The third is at 20s and 21s which is where the application is opening and rendering its screen. The last spike at 69s happens when the application was shutting down and storing its data.

Network Usage

In this run, we will not have any network usage as the run was performed on a wired computer which has no cell or Wi-Fi data transmissions. However we should know that cell service transmissions can be a real drain on battery life if they are used to communicate a large block of data. This is because the radio is constantly moving down from and back up to a higher energy level as it separates the block of data into smaller blocks for the cell network and transmits/receives them.

Doughnut Graph

This graph is shown on the right side of the report.

pic11

The paragraph at the bottom indicates how long a ‘Standard Battery’ would last if the user did the same operations for about 11 hours. According to Microsoft the algorithm to determine the battery life uses a software model trained on lower-end devices. So a ‘Standard Battery’ here is a battery typically found on lower-end devices.

A typical use for this information is to first baseline a set of operations in your application to see how much energy was used. If that level is considered too high, the application should be refactored and this report would be ran again.

XAML UI Responsiveness

A key to meeting the Fast and Fluid pillars is to keep the app rendering at 60 FPS. Visual Studio 2013 has a diagnostics tool named ‘XAML UI Responsiveness’ which addresses how responsive your XAML UI is.

The tool is ran just like the Energy Consumption tool described earlier. Open your project and press Ctrl+Alt+F9 and check the XAML UI Responsiveness tool:pic12

After you press the Start button your application will start and you should use the target portion of your application for which you want the diagnostics. Then go back to Visual Studio and click ‘Stop Collection’ link.

XAML UI Responsiveness Report

After clicking the link you will see a report such as this one:

pic13

This report is divided into four swim lanes.

Swim Lane 1

Shows how long the application ran during this diagnostic. You can click and drag to limit the other swim lanes to a specific time slice of the run. Note that you can click and drag on swim lanes 1-3.

Swim Lane 2

Shows the CPU utilization on the UI Thread separated into 4 categories:

Parsing

Occurs during parsing of the XAML into a tree of XAML elements.

Layout

Occurs when the XAML element tree is positioned and transformed into the visual tree.

Per Frame Callback

Occurs on code defined in the Composition Target.Rendering callback.

XAML Other

Any other application code executed during UI processing is shown in this category. For example, modifying an elements RenderTransform on a timer.

Swim Lane 3

Shows our key element (frames per second) during the run of the application. The FPS is measured on the UI thread and on the Composition thread.

UI Thread

This thread is responsible for running per frame callbacks (CompositionTarget.Rendering) as well as parsing the XAML and building the XAML element tree. It lays the element tree by measuring, arranging, and applying styles to each element. And last it will take the element tree and build a visual tree by rasterizing each element.

In the screen shot above you’ll notice that the UI FPS is much lower than 60 FPS. This is ok since the Composition Thread is running at 60 FPS which means the UI Thread is feeding the Composition Thread the rasterized elements fast enough for it to reach 60 FPS.

Composition Thread

Performs any independent translations and sends the rasterized visual tree to the GPU.