[m-rev.] diff: add library routines for controlling profiling

[Julien Fischer]

On Wed, 27 Sep 2006, Julien Fischer wrote:

>
> On Wed, 27 Sep 2006, Ian MacLarty wrote:
>
>> On Wed, Sep 27, 2006 at 05:28:22PM +1000, Julien Fischer wrote:
>>> 
>>> On Wed, 27 Sep 2006, Ian MacLarty wrote:
>>> 
>>>> On Wed, Sep 27, 2006 at 08:19:41AM +0200, Peter Ross wrote:
>>>>> Hi,
>>>>> 
>>>>> 
>>>>> ===================================================================
>>>>> 
>>>>> 
>>>>> Estimated hours taken: 1
>>>>> Branches: main
>>>>> 
>>>>> library/benchmarking.m:
>>>>> 	Programmatically turn profiling on and off.
>>>>> 
>>>>> 
>>>>> Index: library/benchmarking.m
>>>>> ===================================================================
>>>> ...
>>>>> +
>>>>> +:- pragma foreign_decl(c, local, "
>>>>> +#include ""mercury_prof.h""
>>>>> +#include ""mercury_heap_profile.h""
>>>>> +").
>>>>> +
>>>>> +:- pragma foreign_proc(c, turn_off_call_profiling,
>>>>> +        [will_not_call_mercury, thread_safe, tabled_for_io], "
>>>> 
>>>> tabled_for_io doesn't have any effect if there are no io state arguments
>>>> (even if the proc is impure).  I'm not sure you want to table these
>>>> anyway, since I wouldn't imagine anyone would want to debug and profile
>>>> their program at the same time.
>>> 
>>> Yes, but the calls to them might still be in a program that is being
>>> debugged.
>>> 
>> 
>> But such calls would be no-ops, so tabling would be unnecessary.
>
> They're foreign code; how is the Mercury compiler to know that they
> are no-ops?
>
>> Anyway consider if these were tabled and you were debugging and
>> profiling the program at the same time.  Suppose profiling were turned off 
>> at
>> program start and then turned on half way through a long computation.
>> Then suppose you perform a retry to somewhere before the profiling is
>> turned on.  Now on re-execution you'll get profiling of parts of the
>> program where profiling should be been turned off and double-profiling of 
>> other
>> parts.  Of course disabling tabling won't change this, but it seems
>> silly to have a tabled_for_io there when that's not going to do anything
>> useful.
>
> It's not silly to have it there if it stops the debugger complaining
> about unsafe retries - which is presumably why you would put it there.

I was assuming there at you don't want to enable debugging and profiling
at the same time, which for end users will always be the case.
(Does debugging and profiling together even work?)

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------