[m-dev.] Performance of collect

[Erwan Jahier]

| On 22-Sep-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
| > > Breakpoint 1, MR_COLLECT_filter (seqno=0, depth=4290683468, port=1356800, 
| > >     layout=0x1520d8, path=0x16 <Address 0x16 out of bounds>, 
| > >     stop_collecting=0xff1c84c0 "") at mercury_trace_external.c:1486
| > > 1486            if (MR_collect_arguments) {
| > 
| > This already shows several errors: the values of seqno, depth, port and path
| > all look invalid.
| 
| gdb often shows invalid values for function parameters when you
| set a breakpoint on a function.  Often you need to step through
| at least one statement until you are past the function prologue;
| only then will gdb show the correct values for the function
| parameters.  If you've compiled with `-O' or `-O2', as is the default
| for Mercury, this may take several "step" comands.
| (This effect is platform-dependent.)

That's what I was suspecting (and hoping too ;-)

-----------------------------------------------------
I am still in the process to understand why collect(nop, _) (where nop define 
a monitor that does nothing) is so slow.

Currently, with 11-queens (34 000 000 events) the timings are:

off line, no trace info: ~4s
mdb ./queens11 < finish: ~20s
collect(nop, Result)   : ~200s (now) 
collect(nop, Result)   : ~800s (before I move MR_COLLECT_filter to MR_trace_real()) 

If I remove the call to filter in mercury_trace_external: 80s
 
If I remove the call to filter in mercury_trace_external
*AND* I remove the save_regs/restore regs statements    : 20s

So the save_regs/restore regs statements seems to cost me 40s, and the call to
*filter_ptr() (which does nothing with nop monitor) seems to cost 120s.

Why is this call so expensive? 

It could be due to the fact that the input arguments of filter_ptr() are called
by values, but those values are not so big (an hanfull of integers and
predicate names). Moreover, if I initialize the collecting data (that is also
passed by value) to a string of 1000 characters, I do not have a noticeable
change of timings.


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