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

[Paul Bone]

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.

I agree with your proposal.

> >I would also like to propose renaming the --profile-for-implicit-parallelism
> >option to --profile-for-feedback.  This name reflects the more general
> >ability of this grade to be used for any type of profile feedback optimization,
> >not that any other uses for feedback analysis exist at the moment.
> 
> Under my proposal it wouldn't be necessary although you could add it as
> a synonym for --profile-optimized if you wish.

I'll probably do that, I think the synonym is helpful to people are searching
for an option that gets them feedback analysis.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20111107/768382cf/attachment.sig>