library(port_profiler)

Port Counting Profiler [more]

Predicates

last_port_profile(++Options)

Output another port profile for the most recently profiled goal

port_profile(?)

No description available

port_profile(+Goal, ++Options)

Create a (box model) port profile for the given Goal execution

Description

This is a performance analysis tool based on counting of events during program execution. The events that are counted are defined in terms of the 'box model' of execution (the same model that the debugger uses). In this box model, predicates are entered though call, redo or resume ports, and exited through exit, fail or leave ports. In addition, other interesting events are indicated by ports as well (next, else, delay).

The usage is as follows:

Compile your program in debug mode, as you would normally do during program development, e.g.
```
    	?- compile(queen).
    
```
Load the port_profiler library
```
    	?- lib(port_profiler).
    
```
Run the query which you want to examine, using port_profile/2:
```
    	?- port_profile(queen([1,2,3,4],Out), []).
    
```
This will print the results in a table.

The default output you get looks like this:

	PREDICATE       CALLER               call     exit     fail    *exit     redo
	store_set   /3  nodiag      /3        106      106        .        .        .
	-           /3  nodiag      /3         46       46        .        .        .
	=\=         /2  nodiag      /3         46       45        1        .        .
	qperm       /2  qperm       /2         30       28        .       16       14
	qdelete     /4  qperm       /2         20       18        .       12       10
	nodiag      /3  nodiag      /3         17       14        3        .        .
	nodiag      /3  safe        /1         17        7       10        .        .
	+           /3  nodiag      /3         17       17        .        .        .
	qdelete     /4  qdelete     /4         10        9        .        3        2
	qperm       /2  queen       /2          1        .        .       11       10
	safe        /1  queen       /2         11        1       10        .        .
	safe        /1  safe        /1          7        4        3        .        .
	queen       /2  trace_body  /2          1        .        .        1        .

The port counts give information about

what are the most frequently called predicates (call ports)
whether predicates failed unexpectedly (fail ports)
whether predicates exited nondeterministically (*exit ports), i.e. whether they left behind any choice-points for backtracking.
whether nondeterministically exited predicates were ever re-entered to find alternative solutions (redo ports).
whether predicates did internal backtracking (next ports) in order to find the right clause. This may indicate suboptimal indexing.
how often predicates were delayed and resumed.

By default, statistics are collected separately for each predicate-caller pair, i.e. multiple lines appear for a predicate when it is called from different caller predicates. This feature can be disabled so that predicates are not distingushed by their caller. It is also possible to restrict data collection to predicates with a spy point only (less time consuming).

Other options allow output in different formats, e.g. as an html file, with a subset or different order of the ports, or with module information. For details, see the description of port_profile/2.

Related, but different tools are:

The sampling profiler (profile/1,2 from lib(profile)): this works even on optimized, non-traceable code and gives timing information. It does not give information about the caller predicate.
The coverage analyzer (see lib(coverage)): this is also based on counting, but has counters for every program point and is probably less useful for performance analysis.

About

Author: Joachim Schimpf, IC-Parc
Date: $Date: 2012/02/06 13:24:43 $

Generated from port_profiler.eci on 2022-09-03 14:26