Profiling Implementation

The approach described above has two basic advantages. First, instrumenting at the source code level makes it very portable. Second, different implementations of the profiler can be easily created by providing different code for the constructor and destructor. This makes it very flexible. Currently, we have implemented two versions of the profiler:

Direct Profiling:

The function profile is directly computed during program execution. We maintain a set of performance data values (#numcalls, usec, cumusec) for each profiled function. In addition, we store the current and parent function identifications and the timestamp of function entry in the Profiler object. These three values are set by the constructor, which also increments the counter #numcalls. The destructor uses the entry timestamp to compute the duration of the function call and adds this value to the corresponding usec and cumusec fields, but also subtracts it from the usec field of its parent function. In this way, we can compute the time spent in a function itself not counting its children. At the exit of the main function, all profile data gathered for all functions is written to a file by the destructor.

Trace-based Profiling:

Here the constructor and destructor functions simply call an event logging function from the pC++ software event tracing library (see next subsection). All events inserted are assigned to the event class EC_PROFILER. By using event classes, the event recording can be activated/deactivated at runtime. The computation of the profile statistics is then done off-line.

Other profiling alternatives could be implemented in the same way. For example, profiling code could be activated/deactivated for each function separately, allowing dynamic profiling control. Another possibility is to let users supply function-specific profile code (specified by source code annotations or special class members with predefined names) that allows customized runtime performance analysis.