Process Profiling

Windows CE .NET

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

  1. Build a profile-enabled kernel.

    See Creating a Profile-Enabled OS Image for a CEPC.

  2. 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:

    1. Add a line in the project.bib file.
    2. Copy the .exe and .map files in the release directory.
    3. 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)
    
  3. 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() and void 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

Monte Carlo Profiling


 Last updated on Friday, October 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.

Show: