Skip to main content

WP7: Know your data

If you've been developing Windows Phone 7 apps you'll be aware of the '90 MB' memory limit guideline detailed in the application certification requirements, if not it says:

5.2.5 Memory Consumption An application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory. You can use the DeviceExtendedProperties class to query the amount of memory that is available 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.

I've heard of apps exceeding this limit and still being approved for the app store, but that is not the point of this post, the point is as a developer working on a device you should have a cursory knowledge of the size of your data. The reason is simple because when you exceed the 90 Mb limit (and in all probability you will) you'll be able to identify where your memory problems are quicker and more efficiently.

Rich & I are building a couple of applications for the platform as well as getting WP7Contrib up & running and we've run into issues with the memory limit. We know we are because we're using the excellent memory diagnostics helper from Peter Torr. The problem is we're exceeding the limit with what appeared to be a very limited amount of data (a results set of 40 items). Now we've a good idea of where the problem is - XAML, but we're unable to say with any confidence this was the real cause of our problems. After all the application involves calling back end services, getting the data back, transforming the data, caching the data as well as pushing it into observable collections and binding to the UI. So whilst Rich had a look at the XAML, data templates and ways to lazy load items and images I concentrated on analyzing our data model.

How was I going analyze the memory usage of our data model?

A quick search highlighted the issue there doesn't appear to a memory profiler out there for WP7 - I could be wrong! So next I thought why not and try measure the 'size of' the model at runtime, but how do you measure the size of a reference type? Simply you can't - 'sizeOf' is for value types only and 'Marshal.SizeOf' only shows the unmanaged size after marshalling, not the actual size in memory.

I then thought I don't want an exact figure just an indicative idea of the size, I could use serialization - serialise the model to a byte array and display the length, not perfect but okay.

The following are steps I used to to measure memory size of our model.

1. Create an observable collection to hold the instance of the model,
2. Serialise the empty observable collection and get the length of the array,
2. Get current application memory usage via the DeviceExtendedProperties methods,
3. Make request to back end service and result to observable collection,
4. Serialise the updated observable collection and get the length of the array,
5. Calculate the average size of a serialized collection item by dividing the length by the number of items in the collection,
6. Call GC.Collect - clear down any freed memory (at least request a sweep),
7. Get current application memory usage again and calculate delta.

Note: I didn't bind the observable collection to the UI, I purely wanted to measure the size of the model when contained in an observable collection.

I then took the results of these steps and displayed them on a simple UI.



The import information to take from the screenshot:

Number of items in the collection = 378
Serialized size of collection = 346,538 Bytes
Average size of serialized item = 916 Bytes

The current memory usage = 12,865,536 Bytes

You can also see the output from Peter Torr's memory diagnostic helper at the right hand side of the screen - 11,512 KBytes.

So from these figures I am able to deduce the model isn't causing our application to directly exceed the 90 MB limit and we've gained a greater understanding our data model - we now know our data model.

Note: We would never try and display so many items on a device, it's just a test...
Labels:

Comments

  1. Anonymous26 January 2012 at 12:58

    thanks for info !

    ReplyDelete
  2. in-memory analytics26 January 2012 at 13:56

    Hey :), thanks for sharing such a well written post with us. I read it till the last and indeed impressed with the way you expressed everything in above article. The best thing is taking the result of every steps & displaying them on a simple UI. Nice !

    ReplyDelete

Post a Comment

Popular posts from this blog

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v
Post a Comment
Read more

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below
5 comments
Read more

Custom AuthorizationHandler for SignalR Hubs

How to implement IAuthorizationRequirement for SignalR in Asp.Net Core v5.0 Been battling this for a couple of days, and eventually ended up raising an issue on Asp.Net Core gitHub  to find the answer. Wanting to do some custom authorization on a SignalR Hub when the client makes a connection (Hub is created) and when an endpoint (Hub method) is called:  I was assuming I could use the same Policy for both class & method attributes, but it ain't so - not because you can't, because you need the signatures to be different. Method implementation has a resource type of HubInnovationContext: I assumed class implementation would have a resource type of HubConnectionContext - client connects etc... This isn't the case, it's infact of type DefaultHttpContext . For me I don't even need that, it can be removed completely  from the inheritence signature and override implementation. Only other thing to note, and this could be a biggy, is the ordering of the statements in th
Post a Comment
Read more