[m-dev.] Proposing a new grade component.

[Julien Fischer]

On Mon, 7 Nov 2011, Paul Bone wrote:

> On Mon, Nov 07, 2011 at 04:05:56PM +1100, Julien Fischer wrote:
>>
>> I would prefer to avoid adding yet another grade component if possible.
>> In this case, provided that the overhead of enabling
>> --coverage-profiling is acceptable then we should just enable that by
>> default and just use *.gc.profdeep grades for feedback as well as profiling.
>>
>> When profiling for feedback, you would need to compile with
>> --profile-optimized enabled.  While this would only affect your program
>> modules, I suspect this is ok since most performance critical
>> procedures in the standard library will (should) be opt_imported into
>> one of your program modules anyway.  Once there, they *can* be compiled
>> with it enabled.
>>
>
> I also wish to avoid creating new grades, they're a source of confusion for
> many users.
>
> Coverage profiling introduces a slowdown of roughly 6% (see my honours thesis).
> However, this may have changed since I made coverage data associated with the
> dynamic deep profiler structures and not the static structures, that is to say,
> now it is collected and stored like the other profiling data.

Given that it may have changed then I suggest you measure it again.

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