Saturday 9th February 2013: 11.59pm.
All virtual machines were configured with a 1280x768x32pp screen, 1Gb RAM, 2 CPUs running x86 (except where mentioned). Compression was performed by Lempel-Ziv-Markov chain analysis using a 512Mb dictionary size (which needs about 5.4Gb during its run), so compression ought to be very good at spotting duplicated assets in physical memory. None of the VMs claimed to need to use any swap.
The first thing which screams out at you is Windows Phone 8. Somehow they squeeze the same amount of entropy as Windows 7 x64 has (which make sense as they're the same OS) into a quarter of the physical RAM. This suggests that they're using a compressed in-memory swap file - or that Hyper-V, the VM implementation Microsoft forces you to use, compresses the memory image it saves out when exporting (I couldn't get Microsoft's tool for dumping a straight memory dump to work). I'm inclined to think the former, because even though they halved the just booted working set in Windows 8 (http://blogs.msdn.com/b/b8/archive/2011/10/07/reducing-runtime-memory-in-windows-8.aspx), their Fast App Resume feature strongly suggests that an app's working set gets stored away somewhere. Also, we know they use an on-flash page file, and to reduce flash wear it is highly advisable to compress pages. And finally, we know they guarantee that a 512Mb RAM device can run an app with a 180Mb working set, which implies they assume 152Mb for the system (512-2*180=152) which is exactly the amount saved out by Hyper-V for a just booted Windows Phone 8, a value too coincidental for my first interpretation not to be true.
Thoughts? Questions? Comments? All welcome here.
#android #windowsphone #windowsphone8 #wp8 #windows #windows7 #memoryconsumption #workingset #memoryefficiency