## 4.41 Execution profiling

This section describes the hierarchical execution profiler. This profiler is based on ideas from gprof described in Graham et al., 1982. The profiler consists of two parts: the information-gathering component built into the kernel,144There are two implementations; one based on setitimer() using the `SIGPROF` signal and one using Windows Multi Media (MM) timers. On other systems the profiler is not provided. and a presentation component which is defined in the `library(statistics)` library. The latter can be hooked, which is used by the XPCE module `library(swi/pce_profile)` to provide an interactive graphical frontend for the results.

### 4.41.1 Profiling predicates

The following predicates are defined to interact with the profiler.

profile(:Goal)
  Execute Goal just like once/1, collecting profiling statistics, and call `show_profile(`[]`)`. With XPCE installed this opens a graphical interface to examine the collected profiling data.
profile(:Goal, +Options)
  Execute Goal just like once/1. Collect profiling statistics according to Options and call show_profile/1 with Options. The default collects CPU profiling and opens a graphical interface when provided, printing the `plain' time usage of the top 25 predicates as a ballback. Options are described below. Remaining options are passed to show_profile/1.
  time(+Which)
    If Which is `cpu` (default), collect CPU timing statistics. If `wall`, collect wall time statistics based on a 5 millisecond sampling rate. Wall time statistics can be useful if Goal calls blocking system calls.
show_profile(+Options)
  This predicate first calls prolog:show_profile_hook/1. If XPCE is loaded, this hook is used to activate a GUI interface to visualise the profile results. If not, a report is printed to the terminal according to Options:
  top(+N)
    Show the only top N predicates. Default is 25.
  cumulative(+Bool)
    If `true` (default `false`), include the time spent in children in the time reported for a predicate.
profiler(-Old, +New)
  Query or change the status of the profiler. The status is one of
  false
    The profiler is not activated.
  cputime
    The profiler collects CPU statistics.
  walltime
    The profiler collects wall time statistics.

  The value `true` is accepted as a synonym for `cputime` for compatibility reasons.

reset_profiler
  Switches the profiler to `false` and clears all collected statistics.
noprofile(+Name/+Arity, ...)
  Declares the predicate Name/Arity to be invisible to the profiler. The time spent in the named predicate is added to the caller, and the callees are linked directly to the caller. This is particularly useful for simple meta-predicates such as call/1, ignore/1, catch/3, etc.

### 4.41.2 Visualizing profiling data

Browsing the annotated call-tree as described in section 4.41.3 itself is not very attractive. Therefore, the results are combined per predicate, collecting all callers and callees as well as the propagation of time and activations in both directions. Figure 5 illustrates this. The central yellowish line is the `current' predicate with counts for time spent in the predicate (`Self'), time spent in its children (`Siblings'), activations through the call and redo ports. Above that are the callers. Here, the two time fields indicate how much time is spent serving each of the callers. The columns sum to the time in the yellowish line. The caller <recursive> is the number of recursive calls. Below the yellowish lines are the callees, with the time spent in the callee itself for serving the current predicate and the time spent in the callees of the callee ('Siblings'), so the whole time-block adds up to the `Siblings' field of the current predicate. The `Access' fields show how many times the current predicate accesses each of the callees.

The predicates have a menu that allows changing the view of the detail window to the given caller or callee, showing the documentation (if it is a built-in) and/or jumping to the source.

Figure 5 : Execution profiler showing the activity of the predicate chat:inv_map_list/5.

The statistics shown in the report field of figure 5 show the following information:

- samples
  Number of times the call-tree was sampled for collecting time statistics. On most hardware, the resolution of `SIGPROF` is 1/100 second. This number must be sufficiently large to get reliable timing figures. The Time menu allows viewing time as samples, relative time or absolute time.

- sec
  Total user CPU time with the profiler active.

- predicates
  Total count of predicates that have been called at least one time during the profile.

- nodes
  Number of nodes in the call-tree.

- distortion
  How much of the time is spent building the call-tree as a percentage of the total execution time. Timing samples while the profiler is building the call-tree are not added to the call-tree.

### 4.41.3 Information gathering

While the program executes under the profiler, the system builds a dynamic call-tree. It does this using three hooks from the kernel: one that starts a new goal (profCall), one that tells the system which goal is resumed after an exit (profExit) and one that tells the system which goal is resumed after a fail (i.e., which goal is used to retry (profRedo)). The profCall() function finds or creates the subnode for the argument predicate below the current node, increments the call-count of this link and returns the sub-node which is recorded in the Prolog stack-frame. Choice-points are marked with the current profiling node. profExit() and profRedo() pass the profiling node where execution resumes.

Just using the above algorithm would create a much too big tree due to recursion. For this reason the system performs detection of recursion. In the simplest case, recursive procedures increment the `recursive' count on the current node. Mutual recursion, however, is not easily detected. For example, call/1 can call a predicate that uses call/1 itself. This can be viewed as a recursive invocation, but this is generally not desirable. Recursion is currently assumed if the same predicate with the same parent appears higher in the call-graph. Early experience with some non-trivial programs are promising.

The last part of the profiler collects statistics on the CPU time used in each node. On systems providing setitimer() with `SIGPROF`, it `ticks' the current node of the call-tree each time the timer fires. On Windows, a MM-timer in a separate thread checks 100 times per second how much time is spent in the profiled thread and adds this to the current node. See section 4.41.3.1 for details.

#### 4.41.3.1 Profiling in the Windows Implementation

Profiling in the Windows version is similar, but as profiling is a statistical process it is good to be aware of the implementation145We hereby acknowledge Lionel Fourquaux, who suggested the design described here after a newsnet enquiry. for proper interpretation of the results.

Windows does not provide timers that fire asynchronously, frequent and proportional to the CPU time used by the process. Windows does provide multi-media timers that can run at high frequency. Such timers, however, run in a separate thread of execution and they are fired on the wall clock rather than the amount of CPU time used. The profiler installs such a timer running, for saving CPU time, rather inaccurately at about 100 Hz. Each time it is fired, it determines the CPU time in milliseconds used by Prolog since the last time it was fired. If this value is non-zero, active predicates are incremented with this value.