Using the I/O Profiler

The File I/O and Synchronization Win32 API Profiler (FIOSAP) is an outgrowth of WAP designed to profile applications that possibly have multiple concurrent threads. The Windows NT File I/O and Synchronization APIs are contained in the KERNEL32.DLL. The profiler is in the form of a single FERNEL32.DLL, corresponding to the KERNEL32 DLL. This DLL sits between an application and KERNEL32.DLL, intercepts file I/O and synchronization API calls to KERNEL32.DLL, and then makes and times a call to the actual API. It also collects various statistics useful in monitoring the overall file, event, mutex and semaphore activity of the application(s).

FERNEL32.DLL reports the number of operations, total time and average time in each operation, as well as the additional statistics for some of these operations. The following list shows exactly what additional operations are measured. Times are expressed in microseconds.

The profiling DLL also records the following information for each synchronization (event, mutex, or semaphore object) handle that the process uses:

To profile a list of applications with FIOSAP, type:

apf32cvt fernel32 <app list>

where <app list> is a list of one or more names of the executable applications or DLLs that are to be profiled during the profiling run. As with WAP, <app list> must be the last argument to apf32cvt. For the Zapdata application we are looking at in this example, we type:

apf32cvt fernel32 zapdata.exe

In the next two figures we show part of the results of the run of FIOSAP on Zapdata.

Figure 10.16 Partial FIOSAP file statistics on the Zapdata application

Figure 10.17 Partial FIOSAP event and semaphore statistics on the Zapdata application

Data from FIOSAP is written to FERNEL32.END, in the working directory of the application. FIOSAP will write data from concurrent multiple threads to the same data file, and there is no method for separating the data based upon threads. However, FIOSAP will write data from concurrent multiple processes to different data files, as long as the profiled concurrent processes have different working directories. If you have two concurrent processes with the same working directory, the data for one of them will be lost.

So now, if you have an application and you want to know what it is waiting for when it is not burning up the processor, you know just what to do.