[m-dev.] Advice needed on benchmarking library

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Oct 30 12:52:06 AEDT 2000


On 27-Oct-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> I need to knock up a benchmarking library to count various events and
> I don't want to have to thread some extra bit of state throughout my
> program.
> 
> The interface I'm planning will look something like this:
> 
> :- module bmctr.
> :- interface.
> :- impure pred init(string::in) is det.
> :- impure pred reset(string::in) is det.
> :- impure pred inc(string::in) is det.
> :- semipure func value(string) = int.
> 
> Each event of interest is given a string identifier by the programmer
> who then augments the program with appropriate calls to bmctr.
> 
> It would be simplest if I could implement this in Mercury as, say, a
> map(string, int) and just keep a persistent pointer to the counter
> map using the C interface.  However, I don't know what the implications
> are re: garbage collection with this approach - I suspect bad things
> might happen.

Right.  For the conservative collector, this is OK, but for other
memory management policies, bad things might happen.
For `--gc none', we recover heap on backtracking.
So whenever you store a Mercury value in a global variable, if you
want its value to persist after backtracking, you need to call
MR_make_permanent(), which is defined and documented in
runtime/mercury_deep_copy.h.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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
--------------------------------------------------------------------------



More information about the developers mailing list