Process Profiling
Process profiling periodically examines which routine is currently running, and memorizes its name and the module it belongs to. The module name consists of the .exe or .dll file name. This analysis is not limited to the system processes (Nk.exe, Filesys.exe, Device.exe, and so on). User processes can be monitored as well.
The profiler uses a periodic interrupt to take samples. This interrupt calls a profiler routine (ProfilerHit), which memorizes the Instruction Pointer (IP) of the interrupted routine or identifies it. The identification process is based on the Windows CE table of contents analysis according to the address of the interrupted routine. Only modules that are part of the Windows CE image can be identified.
The ProfilerHit routine can perform the identification process immediately (nonbuffered method) or defer identification until the end of the sampling period (buffered method). The nonbuffered method requires less memory but is more intrusive. Users should be aware that the identification process could last for a period of time, because it involves scanning the table of contents until the address of the interrupted routine is found.
Process profiling is only a statistical tool, but it is considered very useful in identifying where most of CPU time is spent.
To set up Monte Carlo process profiling
Build a profile-enabled kernel.
Profile a user application.
The profiler can identify only those applications that are part of the Windows CE image. Such user applications will have a table of contents entry and therefore will not remain unknown. But having a table of contents entry is not enough to let the profiler identify the application routines. The table of contents must contain a profiler section relating to the user application.
Including an application in a Windows CE image requires a .bib file modification: Add the application in the MODULES section of the project.bib file. This application can be compressed or not.
Note It is not possible to include this application in the FILES section because it will not have a table of contents entry. The build process needs the .map file of the included application to create the profile header in the table of contents.
In brief:
- Add a line in the project.bib file.
- Copy the .exe and .map files in the release directory.
- Build the image.
You can verify success by examining the table of contents analysis that comes from the build process. For example, does it contain a profile header?
Following is an extract from the table of contents analysis displayed by the Build window in Platform Builder. This platform included two applications: appli1.exe and appli2.exe.
Profile Header 8034ec10 00000420h ( 1056) nk.exe Profile Data 8034f030 000015a8h ( 5544) coredll.dll Profile Data 803505d8 00001f50h ( 8016) filesys.exe Profile Data 80352528 00000b08h ( 2824) appli1.exe Profile Data 80359850 00000070h ( 112) appli2.exe Profile Data 803598c0 00000058h ( 88) nk.exe Profile Syms 8035a398 00002c94h ( 11412) coredll.dll Profile Syms 8035d02c 00004034h ( 16436) filesys.exe Profile Syms 80361060 00001830h ( 6192) appli1.exe Profile Syms 80370a88 000000c0h ( 192) appli2.exe Profile Syms 80370b48 00000090h ( 144)Start and stop profiling.
To launch the profiler simply call the ProfileStart routine. To stop the profiler call ProfileStop. Profiling results are analyzed and "displayed" — that is, sent to a terminal over the debug port.
ProfileStart has two parameters: the sample interval in ms and the profiling mode. The sample interval can be used by the OAL routine (OEMProfileTimerEnable) that set up the ProfilerHit calling period. CEPC profiling implementation does not take care of this parameter. The profiling mode can take the following values:
Profiling mode Description PROFILE_KCALL Kernel call profiling. PROFILE_OBJCALL Object call profiling. PROFILE_BUFFER Buffered profiling. The first three values are mutually exclusive.
Example of process profiling results
The following table of data is produced by process profiling on a Windows CE image that includes and runs a user application appli1.
Note Profiling analysis does not differentiate among overloaded C++ methods. For example,
int myMethod()andvoid myMethod()will both be identified as?myMethod().
This simple application essentially has two threads — one is awaiting the event that the other sets.
The following data is produced by process profiling on a Windows CE image that is based on a sample configuration that includes and runs a user application appli1.
Total samples recorded = 25561
Module Hits Percent
------------ ---------- -------
appli1.exe 17764 69.4
nk.exe 7729 30.2
coredll.dll 68 0.2
Hits Percent Address Module Routine
---------- ------- -------- ------------:---------------------
17715 69 00011040 appli1.exe :?DoNothingThread1
6530 25 8020e50c nk.exe :_KCall
314 1 80218332 nk.exe :_ObjectCall
313 1 80217f42 nk.exe :_GetHandleType
180 0 8020e424 nk.exe :_Int20SyscallHandler
157 0 80212916 nk.exe :_SC_WaitForMultiple
106 0 8021870e nk.exe :_ServerCallReturn
87 0 8020f678 nk.exe :_SC_EventModify
43 0 00011620 appli1.exe :_SetEvent
39 0 01df320a coredll.dll :_xxx_EventModify
24 0 802248fb nk.exe :_SchedLogGetProcessName
14 0 80217e9a nk.exe :_GetObjectPtrByType
12 0 01df3d65 coredll.dll :_UserBlockingBegin
10 0 01df3d6f coredll.dll :_UserBlockingEnd
7 0 01df3278 coredll.dll :_xxx_WaitForSingleObject
3 0 000110e0 appli1.exe :?DoNothingThread2
3 0 00011644 appli1.exe :_EventModify
1 0 80204864 nk.exe :_PICEnableInterrupt
1 0 80204f52 nk.exe :_GetTimerPeriod
Additional details
OAL role
It is the responsibility of the OAL to periodically call ProfilerHit — typically by setting up a periodic ISR. ProfilerHit can be called only within the OAL. Applications have no access to it.
The OAL needs to provide two functions:
- OEMProfileTimerEnable, called by the kernel when the profiler is launched
- OEMProfileTimerDisable, called by the kernel when the profiler is stopped
ProfilerHit routine
ProfilerHit is the kernel routine in charge of taking the profiling samples. It can only be called within the OAL, and has only one parameter — the address of the interrupted function. This address can be obtained by using the GetEPC function, which returns the IP of the interrupted routine.
Buffered versus nonbuffered profiling
Samples can be analyzed immediately (nonbuffered) or stored in a buffer till the end of the profiling period (buffered). By default, the profiler (ProfilerHit) will perform the analysis immediately (nonbuffered). To defer this analysis, the user must set the profiling flags accordingly in ProfileStart.
When buffered profiling is enabled, the profiler will allocate memory from the shared memory pool at launch time and will free it at the end of the profiling period. Each time ProfilerHit is called, it stores the routine address (ProfilerHit parameter) and the index of the table of contents entry for the current process. If the buffer is full, the samples will be discarded. The sample analysis will be performed when the profiling is stopped by a call to ProfileStop.
The sample analysis proceeds as follows:
- Find the interrupted module and routine (table of contents analysis)
- If the module has no table of contents then increment the UNKNOWN process counter
- If the module has a table of contents entry but no profiling header (map file has not been provided during the build image process or the module is compressed), increment the process hit counter (this counter belongs to the table of contents of the module)
- Otherwise increment the routine hit counter (this counter belongs to the table of contents profile header of the module)
See Also
Last updated on Friday, October 08, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.