Out of the box the WP7 emulator offers a way to monitor some performance aspects of a WP7 app by providing the following counters:
- Render thread FPS
- User interface FPS
- Texture memory usage
- Surface counter
- Intermediate texture count
- Screen fill rate
The counters are turned on by default and can be manually turned off by removing the following line in App.xaml.cs (or by changing the flag to false):
<span style="color: #606060" id="lnum1"> 1:</span> Application.Current.Host.Settings.EnableFrameRateCounter = <span style="color: #0000ff">true</span>;
Jeff Wilcox has a great article about the different performance counters and it can be reached from his blog.
What is missing from the emulator is a way to monitor the total memory usage of your application. WP7 app shouldn’t use more than 90MBs of RAM so monitoring the mem usage is crucial. Thankfully, Peter Torr comes to the rescue. He has published a class called MemoryDiagnosticsHelper which adds a total memory usage counter to the application. It’s really easy to use and it blends nicely with the built-in performance counters.
To use the MemoryDiagnosticsHelper, first download it from the Peter’s site. Add the class into your project and then add the following line in your App.xaml.cs, just after the line where the EnableFrameRateCounter is set:
<span style="color: #606060" id="lnum1"> 1:</span> MemoryDiagnosticsHelper.Start(<span style="color: #0000ff">true</span>);
And that’s all that is required. Now you can start your application and see the total memory usage.
In the past few week I’ve used most of my development time developing Windows Phone 7 applications. Here’s a warning for those who are using MVVMLight: Its EventToCommand-feature is leaking memory. So, if you have for example a ListBox, don’t use EventToCommand to bind any functions to the items. Using WeakReference doesn’t help.
Here’s couple screenshots from one application where a listbox contains around 800 objects and every object is touchable. When using MVVMLight the memory usage looks like this after a while:
And here’s a picture where MVVMLight is replaced by using code behind event handlers:
Here’s couple related issue reports from the Codeplex:
Except for this issue, I really like the library.
Until now we’ve been happily using Microsoft’s .NET Oracle driver to connect our applications to the database. But recently we started encountering some strange performance problems. We were able to pinpoint the problem to the DataReader and its Read-method. For some reason, the first call to that method was taking really long even though the DataReader was empty. In some queries the call took around 300 milliseconds and sometimes as long as five seconds.
It was obvious only after we tried it: Switching from Microsoft’s driver to Oracle’s .NET driver brought us dramatic performance benefits. Where before our slowest queries took about six seconds to complete, they were now completing in less than 100 ms. Even the queries which we had considered fast saw drastic changes, dropping from 150 ms to 25 ms.
Previously we had two different test environments. Using the Microsoft’s Oracle driver one of our environments was performing OK and the other one was extremely slow (hence the question on StackOverflow). After changing our application to use the Oracle’s driver instead, our slow environment is now fast. And the previously OK working environment is also much faster than before. What is better, we’re getting consistent performance between both of our environments.
Is Microsoft’s .NET Oracle driver broken? Or is there a catch on using the Oracle’s driver? We’re now going through all the things which are different between the two drivers to get a better picture on the subject. If you have experience on this topic I would be glad to hear from them.
Finally got my blog problems sorted out and hopefully you enjoy this week’s NServiceBus Weekly.
News
Tutorials and Articles
Community
Have a nice week!
Got an interesting NServiceBus related link? Did I miss something? Link not working? Please, send mail or contact @MikaelKoskinen.
It seems one of the Blogengine’s extensions caused some problems, preventing one from opening any of the blog posts from this site. Not sure what happened to cause this. Everything should be working now, though there seems to be some layout problems and ghostly “Submit to DotNetKicks” links.
In case you’re using BlogEngine.net and start getting the “Root Element is Missing” error, try removing every file from the App_Datadatastoreextensions –folder.
