Windows Store apps

The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

4 out of 9 rated this helpful - Rate this topic

General best practices for performance

To deliver great performance for your Windows Store apps for Windows 8, think of performance as a feature. Plan for performance, and measure it early and throughout the lifecycle of your project. Users of Windows 8 expect their apps to remain responsive and feel natural. Treating performance as a feature will help you deliver on this expectation. We discuss general best practices for Windows Store apps using JavaScript and Windows Store apps using C++, C#, or Visual Basic.

Planning for performance

You must plan for every feature in your app, and the same is true for performance. Planning for performance consists of determining what your performance-critical scenarios will be, defining what good performance means, and measuring early enough in the development process to ensure that you can be confident in your ability to hit your goals.

You don't need to completely understand the platform to reason about where you might need to improve performance. By knowing what parts of your code execute most frequently, you can determine the best places to optimize your app.

The users' experience is a basic way to define good performance. For example, an app's startup time can influence a user's perception of its performance. A user might consider the performance of an app's launch time of less than one second to be excellent, less than 5 seconds to be good, and greater than 5 seconds to be poor.

Sometimes you also have to consider other metrics that don't have a direct impact on the user experience. An example of this is memory consumption. When an app uses large amounts of memory, it takes it from the rest of the system, causing the system as a whole to appear sluggish to the user. It is difficult to have a goal on overall sluggishness of the system, so having a goal on memory consumption is reasonable.

When defining your performance goals, take into consideration the perceived size of your app. Users’ expectations for the performance of your app may be influenced by their qualitative perception of how big your app is, and you should take into account whether your users will consider your app to be small, medium, or large. As an example, you might want a small app that doesn't use a lot of media to consume less than 100MB of memory.

Measuring your app’s performance

As part of your plan, you define all of the points during development where you will measure performance. Measuring performance serve different purposes depending on whether measure during the prototyping, development, or deployment phase of your project. In all cases, measure on a representative device so that you get accurate info. For more info about how to measure your app’s performance in Visual Studio, see Analyzing the performance of Windows Windows Store apps.

Measuring your app’s performance during the early stages of prototyping can add tremendous value to your project. We recommend that you measure performance as soon as you have code that does meaningful work. Early measurements give you a good idea of where the important costs are in your app, and inform design decisions. This results in high performing apps that scale well. It can be very costly to change design decisions later on in the project. Measuring performance too late in the product cycle can result in last minute hacks and poor performance.

Measuring your app’s performance during development time helps you:

Determine if you are on track to meet your goals.
If you are not on track, find out early if you need to make structural changes, such as data representation, in order to get back on track.

You don't need to optimize every part of your app, and performance improvements to the majority of your code usually don't result in a material difference to the user. Measure your app's performance to identify the high traffic areas in your code, and focus on getting good performance in only those areas. Often, there is a trade-off between creating software that follows good design practices and writing code that performs at the highest optimization. It is generally better to prioritize developer productivity and good software design in areas where performance is not a concern.

Windows 8 can run on many devices under a variety of circumstances and it is impossible for you to simulate all the conditions in which your app will run. Collecting telemetry about your app's performance on user machines can help you understand what your end-users are experiencing. This can be accomplished by adding instrumentation to various parts of your application and occasionally uploading the data to a web service. From this info, you can determine what the average user sees and what the worst and best case performance of your app is. This will help you decide which aspects of performance to focus on for the next version of your app.

Best practices for Windows Store apps

Let's look at a few key performance best practices that are specific to Windows Store apps.

Test your app on low-power devices

When you create an app, be aware that the type of computer that your users have might have significantly less power than your development environment. Windows 8 was designed with low power devices, such as tablets, in mind. Also, Windows RT uses these same design principles to take advantage of the low power consumption characteristics of ARM-based platforms. Windows Store apps need to do their part to ensure that they perform well on these devices. Operations that seem to run fast on your development machine can have a big impact to the user-experience on a low power device. As a heuristic, expect that a low power device is about 4 times slower than a desktop computer and set your goals accordingly.

Testing your app early and often on the type of computer that you expect the user to have allows you to form a realistic understanding of how your users will experience your app.

Reduce battery consumption

Most of the performance work you do naturally reduces the amount of power your app consumes. The CPU is a major consumer of battery power on devices, even at low utilization. Windows 8 tries to keep the CPU in a low power state when it is idle, but activates it every time you schedule work. You can further reduce your app's consumption of battery power by ensuring that your app doesn't have timers unnecessarily schedule work on the CPU when it is idle. For example, an app might poll for data from web services and sensors (such as the GPS). Consider battery consumption when deciding how often you poll for data.

This is also an important consideration for animations that require constant updates to the screen and keep the CPU and graphics pipeline active. Animations can be an effective in delivering a great user experience, but make a conscious choice about when you use them. This is particularly important for data-driven apps where the user may be looking at your app but not interacting with it. For example, a user may spend a while looking at content in a news reader or photo viewer without interacting with the app. It can also be wasteful to use animations in snap mode because the user is not giving the app their full attention.

Many apps connect to web services to get new info for the user. Reducing the frequency at which you poll for new info can improve your battery consumption.

Reduce memory consumption

Reducing memory helps avoid sluggishness and is even more important for Windows Store apps because of the Process Lifetime Management (PLM) system. The PLM system determines which apps to terminate, in part, by the app's memory footprint. By keeping your app's memory footprint low, you reduce the chance of it getting terminated when it is not being used. For example, you can reduce your app’s memory footprint by releasing unnecessary resources such as images on suspend.

The PLM system may also choose to swap out your app to disk, and swap it back into memory the next time it is switched to. If you lower the memory footprint of your app it will resume faster.