(Note: If words like "RAM" and "ROM" and "XIP" look strange to you, there is an entry here that explains their meanings.)
In my recent "Where's My RAM" entry, I explained why you tend to see a difference between what the WM5 device reports as "Total" RAM and what you know the device actually has. In other words, "Why does my 64M RAM device say it only has 50M?"
In the comments for that entry people asked about the reported "In Use" numbers. "In Use" shows how much of the total RAM the system is using right then. The general consensus among the commenters was that WM5 took three times as much RAM to boot as WM2003 SE.
This was shocking to me, because I know the steps we took to keep that from happening. WM5 is a massive upgrade, with a new OS, new apps, and a ton of new features. We were very worried about bloat, and did a number of things to combat it. We funded a group whose sole job was to analyze performance (including RAM usage) and keep it under control. Those folks did a bunch of work to reduce RAM usage. We also purposely limited the amount of RAM available on the devices our developers used. Almost all of our devices only had 32M of RAM, and the one device that had more, we artificially limited to only use 32M. We didn't want anyone to get lazy.
So, one of our performance guys and I did some analysis to see what's going on here. Did WM5 bloat up and use 3X the RAM that WM2003 SE did? No, it didn't. But, as you'll see, it's very easy to configure your system to use a lot of RAM, and some systems did that.
Granny Smiths vs Jonagolds
The challenge in comparing RAM usage between the two releases is in finding an apples to apples comparison. And, what seemed like a nice place to do that was the emulators that plug into Visual Studio 2005. There you can run both WM2003 SE and WM5 side by side. And, conveniently, it's all Microsoft code. If they're different, it must be our fault.
I did a PocketPC QVGA non-phone image on both. I rebooted and went straight to the memory control panel. WM2003 SE was using 5.16M. WM5 was using 16.80M. Gasp. I clearly had some 'splainin' to do.
It turns out that, while this is a pretty good apples to apples comparison, they're different kinds of apples. The WM2003 SE emulator had been configured to act like it was XIPing. The WM5 emulator had been configured to not act like it was XIPing. Then, to compound the problem, the WM5 emulator doesn't have a page pool configured. So all the code that should have been tucked away in a hidden page pool was actually being loaded into "In Use" RAM. And that code accounted for just a bit under 10M.
So, had we configured the WM5 emulator differently, it would have reported about 7M compared to the previous 5M. That's still some growth, but it's not what I'd call "out of control bloat."
Note that, aside from this discussion and the heart attack the numbers tried to give me, the emulator configuration really doesn't matter. Now that we're aware of this, we may or may not change the emulator configuration for some later SDK. But, even misconfigured the way it is, the WM5 emulator does its intended job perfectly well.
Yeah, but what about the real world?
We got our hands on one particular real world device that the OEM had upgraded, and analyzed the difference in RAM usage between its WM2003 SE image and its WM5 image. This device was also showing about 10M more "In Use" RAM in the later version.
But there were different reasons for this one. We did find that the SE version XIPed while the WM5 one did not. But the WM5 one did use a page pool. So it was configured correctly. Since the page pool comes out of the Total and not the In Use RAM, that wouldn't account for the difference in RAM.
Digging deeper, we found that the Filesystem driver was using 4M more RAM than previously and the display driver was using another 4M more RAM. That 8M, coupled with the 2M we saw in the emulator, pretty much explains the increase.
Now, I don't work with this OEM, so I don't have answers for why these changes were made. But I can speculate.
First, why not XIP? Most storage systems can't be read and written to and the same time. NOR flash can't, NAND flash can't, hard drives can't, and most RAM can't. Typically you access these things through a driver which queues up the requests and guarantees that it doesn't do a read and write at the same time. When you're XIPing, however, it's extremely difficult to enforce this. In WM2003 SE, all you ever did was read from the flash. So it was easy to XIP. WM5 added persistent storage. Now you're writing user data to the flash. XIPing is, in the end, a method of reading code directly from flash. If the code that's writing the user data is being read from the flash, you're reading and writing at the same time. There are ways around this, but it's a very challenging problem. A less error-prone solution would be to stop XIPing. It appears that is what the OEM in question did.
Second, why so much memory in the file system? I'm guessing this also is a result of the move to persistent storage. Flash is slower than RAM, so maybe the OEM was able to get a performance improvement with a large RAM buffer. Does persistent storage require this? No it doesn't. Did the OEM decide it was worthwhile? Maybe.
Third, why so much memory for the display driver? I'm kind of drawing straws here. Maybe they did a lot of buffering for DDraw performance? (DDraw is new in WM5.) I'm not sure.
In the end, however, the OEM saw WM5 give them 32M they didn't have access to before. Persistent storage freed up a ton of RAM. I'm guessing they decided that this enabled them to create some RAM buffers to tune performance. And I'm mostly sure they did this intentionally.
But that's only two examples
Yes, they were the two examples I could get my hands on. But, in both cases, what I see are reasonable reasons for the increased RAM usage. They're certainly confusing to the user. They're even confusing to a developer on the Windows Mobile team. But, in the end, there are explanations for them. They're not just MS bloat.
Mike Calligaro
