[m-dev.] detail profiling

[Fergus Henderson]

On 11-Jun-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> For test coverage analysis, the tool should report the name of any procedure
> that contains either
> 
> - any program point that is not executed that is not after
>   a goal whose determinism says it cannot succeed
> 
> - any program point that is not executed that is not after or just before
>   a goal whose determinism says it cannot succeed
> 
> depending on invocation options.

Printing out just the name of the procedure might not
be enough -- it might be helpful to print out the goal
path too.

Of those two alternaties, I think the second one should
be the default.  Calls to error/1 which never get executed
will be quite common.

> For performance engineering, the tool should order the procedure in profiled
> modules, ordered on
> 
> - the number of times the procedure is called
> 
> - the number of times the most frequently reached program point
>   in the procedure was executed

I guess these two could only give different results for
procedures with determinism nondet/multi.  For other procedures,
the procedure entry point will always be the most frequently
reached point in the procedure, since we don't have loops
(only recursion).

> Two other possibilities, which would
> be a bit more difficult to arrange, are ordering on
> 
> - the number or total size of memory cells allocated in the procedure
> 
> - the number or total size of memory cells allocated at most expensive
>   primitive goal in the procedure

It would also be nice to order on the number of total size of memory
cells allocated in the procedure or in the stuff it calls
(i.e. call graph profiling rather than flat profiling).

> It would also be possibly to envisage equivalents to these two that use
> estimated execution time instead of allocated memory. Estimations
> can be based on such things as the number of memory accesses required
> to fill in a cell, [...]

Why not base such estimations on random sampling, as we currently
do for ordinary (non-detailed) time profiling?

> The tool should of course display the code of the reported procedures as well,
> together with execution counts. The code will be HLDS code, not source, since
> some locations of interest do not correspond to any source location (e.g.
> entries to switches introduced as a result of factoring e.g. a four-way
> disjunction into two two-way switches). There ought to be a way to have
> execution counts displayed the same set of locations as the counters occupy,
> or those locations plus after branched goals (doing the sums for the user),
> or all locations, depending on invocation options.

I think it would be very useful if you could display annotated source code,
in addition to (or perhaps instead of) HLDS code.

If you have execution counts for all HLDS locations, it should be possible
to map those back to counts for source locations, shouldn't it?
(If multiple HLDS locations within a single procedure map to the same source
location, you could just take the maximum; if multiple HLDS locations within
a different procedures map to the same source location then you can
add the counts together.)

> - What form should the output take?

I think the output should (as you suggested) have two parts,
an index section, and a definitions section. 

For the index section, something like our current flat profile
and/or our current call graph profile would be nice.

The definitions section would contain annotated source/HLDS code
for the relevant parts of the program.
For this section, execution counts in a column on the left
and source code on the right would be nice.
If information about memory allocation or execution time is
available too, then that could go in additional columns on
the left hand side.

With regard to test case coverage, it might be also useful to
extend the current flat profiler with an option to report procedures
that are never executed.

Anyway, that should give you some food for thought.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------