[Windows Mobile] tobbbie:
Just the first in the summary:

<Perf Gates>

<Gate Name=Bootup>27813</Gate>

<Gate Name=Memory>33894400</Gate>

<Gate Name=Storage>13049856</Gate>

</Perf Gates>

This is the same as later:

Bootup Time Markers (Milliseconds):

Available RAM on boot = 34242560

Calupd: Exiting = 30226

Initialized appt ssupdate = 29832

Initialized msgcount ssupdate = 29764

SSUpdate: Thread now in message loop = 29231

Calupd: Starting = 28781

SSUpdate: Shell Ready = 28717

Start Menu Icons Fetched = 28687

Appman: Finished Fetching Icons = 28664

Appman: Started Fetching Icons = 27831

Home Painted = 27813

Cprog: Done Booting = 25188

Last Boot Type = 2

I intend to use that setup also to look a little deeper in the devhealth memory report later, to possibly learn about differences that other OSB options are setting to relevant memory allocation of modules - especially dealing with code that can be paged out or not.

From the MSDN/Kernel Blog articles I have read, there are also other (internal) properties of the code that determine if paging may occur or not. Usually SW production tools set the relevant flags of those automatically so you don't have to care yourself.

I am not enough expert to judge here, but from a glance at the devhealth reports I see that e.g. gwes.exe process has no pageable parts (due to OSB setting it like that?) while other processes (e.g. home.exe) do have pageable code.

I was thinking of e.g. setting rilgsm.dll on the list of modules to prevent demand paging (to have the device immediately respond to incoming calls), but I noticed in the report that it already has no pageable (p) pages listed.

To avoid urban legends I wonder if there is a way to determine or even guide which modules/files are candidates for the list of advanced operations in OSB. It could also help to indicate which are clearly not taking any benefit of those.

From what I understand, OSB has a bunch of options that deal with demand paging one or the other way:

Set Kernel Flag 0x00000001 (MSDN: Demand paging is disabled when the first bit of ROMFLAGS is set. When demand paging is disabled, a module is fully loaded into RAM before running. For OEMs that need real-time performance, turning off demand paging eliminates page faults that can cause poor performance.)

Disable demand paging list (need to find out how this is done - dump directory files are still identical to the SYS folder) - I suspect that relevant code section properties are set here. gwes.exe is internally added automatically (see your build log).

imgfs compression options (see the initial compare in the first post) with the related setting to not compress code sections in modules. It may be helpful to balance the ROM size with potential benefit here if there was option to select the modules where the code sections should stay uncompressed. As seen from below comparison it is no benefit for me - but it may for others.

paging pool size (bigger is better - if you can afford it - even set to "unlimited")

In the context of above I still think that wealthy devices with variable use (like smartphones) better profit from PP = 0 than from Kernelflag = 0x00000001 because an "endless" PP still has the potential recovery of paging out when RAM limit is reached while disabled demand paging prevents further loading of modules at all. The latter may be suitable for fixed purpose devices like navigation devices