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...
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...
thanks for info !
ReplyDeleteHey :), 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