[m-dev.] Performance of collect

[Erwan Jahier]

| On 24-Sep-2000, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
| > | You're calling from C to Mercury.  In our current implementation (LLDS back-end),
| > | this is fairly expensive.  
| > 
| > So what about the HLDS back-end then?
| > 
| > Is it ready to use?
| 
| Yes, but not for tracing -- currently it doesn't support the debugger.

Well currently, you can not use the debugger to debug collect programs anyway
(it is dynamically linked code). So ...

The way I currently debug collect/2 Mercury programs is by (1) collecting the
whole trace (with collect/2 ;-), (2) generating a Mercury module that contains
that trace and the definitions of initialize and filter, and (3) applying a
`initialize(Acc0), foldl(filter, Acc0, Acc, Trace)' to it in the main/2
predicate of that module. Of course, this is very brutal and highly
inefficient, but it works; and most of the time, I don't need a large Mercury
program in input to debug my monitors.

| > What would be its overhead? I suppose it does not explicitly make use of 
| > registers etc., so there is no need to save and restore them with this back-end 
| > no?
| 
| The overhead of `pragma export' for the MLDS back-end is very low
| (just one extra function call).
| 
| However, for tracing, the MLDS back-end would need to be modified to
| store all local variables for traced procedures in a struct, rather
| than in registers; that would slow it down quite a bit.

As I have just explained, I can live without trace infos. So the day you add 
trace support for this back-end, please also add an option to turn it off ;-)
 

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