[ Reference Manual | Alphabetic Index ]
Port Counting Profiler
- Output another port profile for the most recently profiled goal
- No description available
- port_profile(+Goal, ++Options)
- Create a (box model) port profile for the given Goal execution
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:
The default output you get looks like this:
- Compile your program in debug mode, as you would normally do during
program development, e.g.
- Load the port_profiler library
- 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.
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
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).
- 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.
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.
- Author: Joachim Schimpf, IC-Parc
- Copyright © Cisco Systems, Inc
- Date: $Date: 2009/02/19 05:38:37 $
Generated from port_profiler.eci on 2009-02-24 09:44