Performance Analyzer for Windows Runtime apps using JavaScript
The Performance Analyzer for Windows Runtime apps using JavaScript is a tool that enables developers to identify common performance issues within their Windows Runtime apps using JavaScript. Users expect apps to respond immediately to touch, taps, clicks, gestures, and key-presses. Additionally, users expect smooth animations and quick load times. The performance analyzer for Windows Runtime apps using JavaScript enables developers to test their apps in a wide variety of common scenarios.
Installing and running the tool
The Performance Analyzer for Windows Runtime apps using JavaScript is a tool that comes with the Windows 8 software development kit (SDK).
To install and run the tool:
- Download and install the Windows 8 SDK: go to Downloads for developers, find the Download tools and SDK heading, and click the Download now button.
- After you install the SDK, you can find a version of the tool for each architecture at the location where the SDK was installed:
- The version that runs on ARM is typically located at C:\Program Files (x86)\Windows Kits\8.0\bin\arm\AppPerfAnalyzer\appperfanalyzer_js.exe.
- The version that runs on 32-bit systems is typically located at C:\Program Files (x86)\Windows Kits\8.0\bin\x86\AppPerfAnalyzer\appperfanalyzer_js.exe.
- The version that runs on 64-bit systems is typically located at C:\Program Files (x86)\Windows Kits\8.0\bin\x64\AppPerfAnalyzer\appperfanalyzer_js.exe.
- If your test machine is not your development machine, copy the AppPerfAnalyzer folder of the appropriate architecture to your test machine.
- Launch the tool by running appperfanalyzer_js.exe.
Windows Store apps can run on a variety of hardware, so run this tool on ARM, Intel ATOM, or AMD Fusion E or Fusion C based machines. The tool runs with admin rights on any app installed for the user. This includes apps installed through Microsoft Visual Studio or the Windows Store. Don't run this tool on an app that is attached to the Visual Studio debugger, because the debugger affects the performance of the app. Only run this tool on trusted apps.
Tests captured in the report
The tool runs these reports:
Activation time
Quick activation is important for a good user experience. This test measures the time it takes your app to activate. Activation time is measured from the time the app's tile is tapped until the time the app returns from the activation event. The most common ways to improve activation time are to load only essential code and resources at activation time, avoid long operations as part of activation, and avoid network-bound operations as part of activation. To learn more about improving activation time, please see Reducing your app's loading time.
UI responsiveness
UI responsiveness is a key contributor to a good user experience. It refers to how quickly an app is able to process and respond to the user's interactions with the UI. This test examines whether your app can respond to user input within an acceptable amount of time. Common ways to improve UI responsiveness include avoiding long operations on the UI thread, offloading work to Web Workers, and appropriately using the setImmediate function when performing work on the UI thread. To learn more about improving UI responsiveness, see Executing code.
Layout passes
The HTML rendering engine must lay out the HTML markup for the screen at load time and each time the app modifies DOM properties that affect layout. Layout passes are an expensive operation because they require many calculations. The app should trigger fewer than 60 layout passes per second and each layout pass should take less than 17ms, on average. Layout passes should also take less than 20% of your app's total CPU time. There are a number of techniques to reduce the number of layout passes, such as using CSS properties or batching the layout operation. To learn more about managing layout passes, see Managing layout efficiently.
Synchronous XMLHttpRequest on UI thread
Synchronous XHR is a blocking operation that, when executed on the UI thread, prevents user interaction with the app. This test detects if any synchronous XHR call is performed on the UI thread. You should use asynchronous XHR calls instead. To learn more, see Executing code.
Image scaling
Scaling an image is an expensive operation that requires extra processing time in addition to the time it takes to decode the image. You should use images that are the size you intend to display. This test detects whether your app scales images. For more info on optimizing image loading and how to design your app for multiple resolutions, see Use thumbnails for quick rendering and Guidelines for scaling to pixel density.
Memory footprint
Apps run better when they use a small amount of memory. An app should have a memory footprint of less than 60MB. To reduce your app's memory footprint, avoid keeping references to objects, such as images or blobs, that are no longer needed.
Runtime broker memory reference set
The Runtime Broker process is used by all apps to communicate with areas of Windows where they are not allowed direct access. A high memory footprint for the Runtime Broker process could indicate improper usage of the broker. This test ensures Runtime Broker's memory footprint is less than 11MB for the reference set and less than 21MB for the working set. If excessive memory usage is detected, the problem is often rooted in excessive open file handles.
Memory leaks
Although JavaScript uses garbage-collection, it is still possible to leak memory. One common cause is circular references between one or more objects that are not referenced by any other object or variable. Because they reference each other, these objects can't be garbage collected. This test looks for increases in memory usage during a 30-second idle state interval that starts 30 seconds after activation. The goal is no more than 10% increase in either the working set or reference set.
Idle state CPU usage
Once an app is up and running, it should reach an idle state where it waits for user input. It is important for battery life that the app minimizes its CPU activity during this idle state. Some apps may require use of the CPU to display animations or perform background activities. This test inspects the CPU usage when the app is idle by analyzing a 30-second interval starting 30 seconds after activation. The app should use less than 3% of the processor while idle.
Successful suspend
A well-behaved app successfully suspends when moved to the background. If an app does not suspend quickly enough when moved to the background, the system terminates it. Resuming an app is faster than re-launching it. This test inspects whether the app fails to suspend within the allotted time. One common cause of failure is trying to save too much state information when suspending. To learn more about how to successfully suspend, see Optimizing your app's lifecycle.
Memory reduction when suspended
To reduce the number of app activations, Windows keeps as many suspended apps in memory as possible. To reduce the likelihood that your app will be terminated, it should reduce its memory footprint when the system suspends it. This test measures the difference in the app's memory usage between when it is active and when it is suspended. To learn more about reducing your app's memory footprint when the system suspends it, see Optimizing your app's lifecycle.
App memory growth
Avoiding continuous memory growth is crucial to keeping your app lightweight. A low memory footprint also allows your app to remain suspended without being terminated by Windows when it moves to the background. This test monitors the memory usage of the app while you use the app and displays a chart showing your app's memory usage. Ideally, the app will show steady or declining memory usage, which means the app is appropriately cleaning up memory. If the chart shows your app's memory usage continuously increases, then your app may have a memory leak that should be investigated.
Runtime broker memory growth
Avoiding continuous memory growth is crucial to keeping your app lightweight. A low memory footprint also allows your app to remain suspended without being terminated by Windows when it moves to the background. This test monitors the memory usage of the runtime broker while you are conducting various tasks within the application, and displays a chart showing your app's memory usage. Ideally, the app will show steady or declining memory usage, which means the app is appropriately cleaning up memory. If the chart shows the runtime broker memory usage continuously increases, then your app may have a memory leak which should be investigated.