[m-dev.] Question about the current Mercury trace

[Erwan Jahier]

Fergus wrote:
| On 26-Sep-2000, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
| > Mark wrote:| 
| > | 	- provide the options '--no-trace-cond' and '--no-trace-negation'
| > | 	  to disable these events.
| > 
| > Ok.
| > 
| > But what about a finer grained way of disabling/enabling events by allowing to
| > enable/disable them one by one? 
| 
| What would that be useful for?

Well, in a process of evaluating the overhead of monitors implemented with
collect compared with hand-written-ad-hoc-hacked-inside-the-compiler equivalent
monitors, I came to the conclusion that the current implementation of collect
suffer from the two following problems:

1 - Calling Mercury code from C code with the LLDS back-end is far too expensive 
(but it seems that the MLDS back-end will not have this problem).

2 - Processing events that you do not use in the monitor can cost a lot. 

Using the module system, it is quite possible to have a certain control over
which procedures to instrument. What is lacking is control over the program
points to instrument.

| > Is that tricky to implement? Or do you fear the extra number of options?
| 
| The latter.

Hmm... with my proposition "mmc --trace [<event type list  to trace>] foo.m",
you actually decrease the number of options since you don't need --no-redo,
--no-internal, --no-negation, etc. anymore ;-)

Ok, but it was just a question anyway. I don't really need it now. If one day I
really miss it, I will come back then.

Actually, it is not clear to me if it is better to recompile the program with
just the needed events or to process the directly the existing execution, even
if it contains too much events. Clearly, there is a tradeoff. and more 
experiments is needed.
-- 
R1.


--------------------------------------------------------------------------
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
--------------------------------------------------------------------------