[Windows Mobile] tobbbie:
I want to share with you some findings on how the size of the paging pool influences the usability of a WM device.

Setup:

Device: HTC Tornado (Smartphone, original WM5, 64MB RAM, 64MB ROM, TI OMAP 850, DiskOnChip from M-Systems)

ROM: my WM6 build (based on Nitrogen's WM6 - see my signature)

ROM Kitchen: OS Builder 1.48

Paging Pool changer: PPSmartchanger (adapted for use without ULDR partition)

Method:

Create builds with OSB selecting the relevant imgfs compression options:

lzx and xpr

with and without having the code sections of modules uncompressed

Change Paging Pool with PPSmartchanger (works only for devices with M-Systems DiskOnChip - so old stuff only - changed with pdocwrite)

retrieve boot-time via devhealth call after device has rebooted to selected standard (for all tests) - 2 repeats have proven enough as there is very little deviation between reboots.

I have taken the boot time because this is easily repeatable and devhealth delivers standardized results.

Results:

lzx delivers the smallest ROM builds but also takes longest time to boot

xpr delivers reasonable sized ROM builds and is the fastest

lzx with uncompressed code sections of modules has large ROMs (larger than xpr) and takes longer time to boot

xpr with uncompressed code sections of modules has giant ROMs (had to cut out all optional parts not impacting the procedure) and is not faster than xpr for all modules

Discussion of the results:

You may ask why that setup first? To learn about the paging pool, look also here.

The Paging Pool serves as a dedicated (limited) area of RAM where the current executed code sections of the loaded modules reside. During boot a lot of modules are loaded. While the boot process continues, the demanded use of the paging pool will intermittently exceed its size and pages (parts of the code sections) are discarded to make room for new code to be loaded to the paging pool. As the discarded pages can easily be re-read from their original location on the imgfs - this is no loss of information.

The time it takes to read a module from imgfs, decompress it (lzx, xpr or no compression) and load it to the paging pool for execution determines the total of the boot time. So if you have an unlimited paging pool or you can afford to switch off the demand paging - then your boot time is limited only by read + decompress.

If now the paging pool is smaller than the maximum sequentially loaded modules need it to be, then the discarding of pages in the paging pool will eventually require a re-load of pages for active modules from the imgfs again. The probability for this to happen will increase with a smaller paging pool, so the boot-times will rise with a smaller paging pool. This is what you see for all 4 setups.

Why is lzx imgfs slower than xpr? lzx files are smaller than xpr on imgfs, so they should be read faster from imgfs! True, but obviously the overhead of the decompression to the paging pool is taking more time over all here for my device. So lzx takes more CPU than xpr for decompression.

Why is xpr + uncompressed code sections slower than if the whole imgfs is xpr? The saved overhead of decompressing the code sections should give an advantage here! So here you see that there needs to be balance of imgfs-read performance and CPU power to decompress. For this device it seems that uncompressed larger code sections are no advantage as they take longer to read from imgfs.

Your device's results may vary, but it seems that you only need to measure for one paging pool setup to judge the different options of OS Builder.