Version 6 (modified by ke, 8 years ago) (diff)



An execution profiler is a tool that helps in analyzing the runtime performance of a program by measuring the number of times that individual parts of the program are executed and/or the time spent while executing each of these parts. This data can be used by decide which parts of the program to optimize, and where restructuring the program could avoid doing unnecessary work. For example, in logic programming, if a predicate fails very frequently, this indicates computations that do not lead to a result and, depending on the program and the data, may be avoided by changing the clause order of a predicate, or changing the goal order in a clause.

Kahina's execution profiler for logic programs counts the number of times each step type (predicate) is called or redone, exits or fails. This is always done automatically as the debugger information from the logic programming system to which Kahina is connected (e.g. TRALE or SWI-Prolog) is recorded. The count information is also implicitly present in the control flow tree and can be computed from it post hoc. The profiler does not yet record the time that passes from entering a step to leaving it, although this is a planned feature.


A profile of (part of) a program is represented as a table whose rows represent step types (predicates). The number of calls, fails, exits and redos of each step type is shown. For additional viewing comfort, the step types may be assigned categories in a manner specified by the concrete layer (e.g. the TRALE layer or the Prolog layer).

TRALE example

For TRALE, steps are currently classified into three categories: rule (rule applications), goal (goal calls) and general (everything else). Future version may have a more fine-grained set of categories, e.g. the one used in the documentation of ALE's source level debugger.

Here is an example profile, made during a parse of the phrase der Mann with a rather heavy-weight grammar:

Different profiles are available in Kahina:

  • The full profile is the profile of the whole program run currently being recorded by Kahina. Show it by clicking Full profile in the Profiler menu.
  • A subtree profile counts only the calls, fails, exits and redos of steps within a certain part of the ControlFlowTree?. This can be useful for assessing the performance of certain parts of a program. Remember that the control flow tree is actually a combined representation of two trees, the search tree and the call tree. So a subtree profile is defined by choosing a root node and then either traversing the search subtree or the call subtree rooted in that node.
    • Show a search subtree profile by first selecting the root node of the desired subtree and then clicking Profile search subtree in the Profiler menu. A search subtree profile may be useful if you know that when control flow hit the root node, a "wrong" choice was made that will not lead to a solution. The profile then shows you the amount of unneccessary work done by the system after making the wrong decision and before failing and backtracking back past the wrong decision.
    • Show a call subtree profile by first selecting the root node of the desired subtree and then clicking Profile call subtree in the Profiler menu. A call subtree profile may be useful for assessing the amount of work that executing a certain step requires, including all substeps.

Warn points

Warn points allow for automatizing certain profiling tasks. With them, you can just let a program run, but stop automatically once the number of calls to a certain predicate (or the number of times a more complex control flow tree constellation has arisen) exceeds a predefined threshold. For example, you can define a number of calls to a certain predicate that you wouldn't expect your program to exceed, and if it does, this is indicatory of a problem. Moreover, the point at which execution is automatically halted because the threshold has been exceeded may indicate the part of execution where things go wrong, for example through infinite recursion.

The warn point system has been integrated with Kahina's BreakpointSystem. This allows to combine arbitrary tree patterns with thresholds, although in typical cases a one-node tree pattern will do. A warn point is a breakpoint paired with a threshold and a counter. The counter starts at 0 and is incremented every time there is a match. Unlike a breakpoint match, a warn point match has no visible effect until the counter hits the threshold. Then, the counter is reset to 0 and Kahina shows the usual breakpoint match behavior: if Kahina is in auto-complete or leap mode, it goes into stop mode, thereby pausing execution of the program. Additionally, a dialog opens indicating which warn point has matched.

Warn points are defined through the warn point editor. This editor is like the other breakpoint editors, except that it has an additional input field for specifiying the threshold.

TRALE example

Let's say your grammar contains the predicate tree_append/3 and you want to be warned if it is called 1000 times. You can define a warn point as follows:

  1. Click Warn points (call tree) in the Breakpoints menu. (Since we are only defining a one-node tree pattern, it does not matter if we choose the call or step tree.)
  2. Click New.
  3. In the Node constraint area, select step label and contains and enter tree_append/3.
  4. Enter a catchy Name for the warn point, such as 1000x tree_append/3.
  5. In the Warn after field, enter the threshold 1000.
  6. Click Apply and quit in the Profile window.

Now start the parse by clicking the leap (fast forward) button. After 1000 calls to tree_append/3, leaping stops and the following window appears:

Attachments (3)

Download all attachments as: .zip