Two for the price of one today!
long deviceTotalMemory = (long)DeviceExtendedProperties.GetValue("DeviceTotalMemory");long applicationCurrentMemoryUsage = (long)DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage");long applicationPeakMemoryUsage = (long)DeviceExtendedProperties.GetValue("ApplicationPeakMemoryUsage");
The Windows Phone 7 Application Certification Requirements specify (as of 28th of September 2010):
5.2.5 Memory Consumption
The application must not exceed 90 MB of RAM usage. However, on devices that have more than 256 MB of memory, an application can exceed 90 MB of RAM usage. The DeviceExtendedProperties class can be used to query the amount of memory on the device and modify the application behavior at runtime to take advantage of additional memory. For more information, see the DeviceExtendedProperties class in MSDN.
Since you have a hard limit of 90MB (exceedable in some cases) it's worth checking that you're not getting anywhere near that while your app is running. The code above will give you the Peak (which is important to make sure you've never crossed the 90MB barrier) and the current memory. If you call that out every now and then you should be able to get a pretty good idea of how your memory fluctuates during the lifetime of the app.
Can I Go Above 90MB?
Sure - but be careful! If you're app is memory intensive and would benefit from a little extra breathing room, then feel free to add some extra logic which dynamically loads more items into memory until a certain limit is hit. Note though that there is no defined limit above the 90MB barrier, so expect this to be clarified in the future.
Kudos go to Stefan Wick, Principal Test Manager for pushing this code
This is kind of obvious - but important. Read the White Paper which was written by the Silverlight performance team (mainly Shane Guillet) and browse through the samples that come with it. In these blog posts I'll try to distill specific items from the paper into blog format, but you can't replace the feel of the complete paper.
Additionally check out the performance video with Shane, which runs through a lot of the samples from the document and distills specific tips and tricks to get your app running smoothly: http://channel9.msdn.com/shows/Inside+Windows+Phone/Inside-Windows-Phone-03-Optimizing-Windows-Phone-Silverlight-applications/
File this one under "Sad, but True"...
Always prefix your source paths with a "/" (full-qualified path) instead of simply using relative paths.
But they both work!?!
True, both of these will work, equally well (visually), but performance wise the relative path will do extra lookups which waste time, and can hit the SD card more than you want it to (causing further slow downs). This is something that we will fix on our side in the future - since all storage is isolated and we can assume that there is always a "/" (if there is no ".."). For now, it doesn't hurt to get the extra performance boost by simply prefixing your paths with a "/".
As Luke Kim, a friend from Microsoft, pointed out "/" paths are not really full qualified paths. To make things clear though, I use the term "full qualified" since we are within the confines of the .NET IsolatedStorage framework and there is no access to the rest of the system, "/" paths are as fully qualified as you get (without actual URI specifiers). Thanks for pointing this out!