[m-rev.] for post-commit review: semantic help pieces for grade options

[Julien Fischer]

On Thu, 17 Jul 2025 at 15:05, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> On Thu, 17 Jul 2025 14:54:38 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > On Thu, 17 Jul 2025 at 01:21, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> > > > I don't think memory rentention profiling is the main thing that memprof
> > > > grades
> > > > are used for, so I would either say:
> > > >
> > > >    Please see the "Using mprof for profiling memory allocation" and
> > > >    "User mprof for profiling memory retention" sections in the Mercury
> > > >    User's Guide for details.
> > > >
> > > > or, if you have to list one only section, point to the allocation one.
>
> OK, I will follow this suggestion.
>
> > > I don't have any objection to this, but I would like to understand the
> > > situation before I make any changes. I don't usually use mprof (I use
> > > the deep profiler instead),
> > > and I don't usually even install the mprof-related
> > > grades, so I am asking you guys: what happens if you invoke mprof -m
> > > on a profile for a program that was compiled in a .prof (but not .memprof) grade?
> >
> > In that specific case, you get a warning:
> >
> >      Warning: error opening `Prof.Counts': can't open input file: No
> > such file or directory
> >     The generated profile will only include call counts.
>
> That seems like a strange diagnostic. It says in effect "I can't get any counts,
> so I will show you only the things I cannot get".

The file is just very confusingly named, the Prof.counts file "records
the number
of times that execution was in each procedure when a profiling
interrupt occurred".
(The Prof.CallPair file records the call counts.)

Julien.