When you are creating application you should always remember about its performance. Application should run smoothly, information about the change progress, response to user actions, etc. In the case of mobile platforms, this problem is even more serious. We are used now, that computers have more powerful multi-core processors, large amount of memory, or fast disk. What was once important in the software development process – the effectiveness of proposed solutions – are often not taken into account. Now, shortcomings in the code are being compensated for by efficient equipment.
The situation is little different in the case of Windows Phone. Since this is a mobile platform, which uses the battery power, its resources are limited. First, we have a weaker processor, limited memory and storage space. Additionally Microsoft decides to introduce some restrictions and requirements for applications. Some of them are:
- displays the first screen in the 5 seconds after starting the application,
- application should be able to respond to user actions within 20 seconds after starting the application,
- application should not take more than 90 MB memory for devices, that have less than 256 MB built-in memory,
- etc.
More details can be found at – Application Certification Requirements for Windows Phone.
Fortunately the Microsoft does not leave you alone, and provides free tools, that allow you to diagnose performance problems. Software developer can use two tools provided by Microsoft:
- profiler,
- performance counters.
The first of these – profiler – allows you to “record” of the application. Data are collected in two modes. Depending on the user’s decision, it obtains information about the application’s performance by analyzing the elements responsible for displaying the application and call various methods in the code. The second option is to check the efficiency of memory usage. Microsoft recommends the first option, unless, that there are problems with memory.
It seems to me, that there is no sense to write about this tool because Maciej has prepared an interesting demo of this tool at Channel9.
The second element that allows for ongoing performance monitoring are counters , that show up on the phone at the moment, when the program is running in debug mode.
Composition Thread Frame Rate
Specifies the number of frames per second displayed by the thread of the composer (composition thread). As part of this thread are executed such operations as: scaling, simple transformations, cropping, rotations, etc. In the case of applications for Windows Phone the optimum value shall be at least 45 frames per second. Smaller values are also sometimes tolerated, However, in a situation of falling below 30 you should think about optimizing. In this case, the counter will turn red.
Quite often it may happen, that this indicator takes the value 0. This situation can occur, when your screen is static and nothing is on it does not change this situation is normal and you should not worry about it.
UI Thread Frame Rate
This counter tells us the number of frames per second generated by a thread UI. Its tasks include the:
- animation support, that can not be handled by the thread of the composer,
- execution of any operation requiring access to UI elements (eg. data binding),
- execution of the code which is located in the elements of UI (eg. Event Handling).
This counter is usually not greater than Composition Thread Frame Rate. It should not drop below 15 frames per second. When this happens then the counter will turn red. Typical value is at least 30 frames per seconds value of this counter, the application to better respond to user behavior.
Interpretation of 0 is analogous to the previous case.
Texture Memory Usage
Indicates the amount of memory occupied by the textures used in the program. This is not the counter memory usage by the program.
This counter is not set limits, and the optimum value. When the first two indicators behave proper way you do not need this analyse indicator.
Surface Counter and Intermediate Surface Counter
The next two I will join together in a single point. In fact, I never found a reasonable use of these two values. The first of these – Surface Counter – determines the amount of space provided for GPU for further processing. Specifically, the amount of surfaces that are transferred from the thread UI to the thread of the composer. The second one counter – Intermediate Surface Counter – tells us how much space has been generated by the action of the composer’s thread.
Fill Rate Counter
The last counter is one of the key elements that is informing us about the performance of applications. Its value indicates the number of pixels generated to display the screen. In this case the 1 means the entire screen, that is 480 * 800 pixels. Following the recommendations of this value, it should not exceed 2,5. In case of exceeding the 3 indicator turns red. The user will notice performance degradation when the rate exceeds 3,5.
Maybe at the beginning seem strange, that to draw one screen there is needed to determine the value of a pixel several times. This behavior occurs for example when the screen displays several animations or images are overlapping each other . At this point, the areas, which are overlapping are drawn several times.
Additional overhead is being created when transparency is used.
In order to optimize this ratio UI must be redesigned, and you should think if all elements should be placed on it. Maybe some are always obscured and can be removed. Additionally, you can also wonder if there are some pictures or graphics, which can be combined into one.
As has already been mentioned counters are available under debug. If you want to use them outside of this mode you should add the following line of code:
Application.Current.Host.Settings.EnableFrameRateCounter = true;
Probably I am not an isolated case, who thinks, that one counter is missing – information about memory usage. This lack can be easily repair by yourself. But more about that in another time.
And finally, one little remark. In the emulator of Windows Phone 7 there is a very strange, but positive effect. Applications tested on the emulator run very often more effectively than on the phone.. For this reason I advice to test the application on the phone before sending it to MarketPlace.
Leave A Comment