[m-users.] Grade for profiling

[Volker Wysk]

Am Dienstag, dem 21.03.2023 um 22:06 +1100 schrieb Julien Fischer:
> Hi Zoltan,
> 
> On Tue, 21 Mar 2023, Zoltan Somogyi wrote:
> 
> > 2023-03-21 20:53 GMT+11:00 "Volker Wysk" <post at volker-wysk.de>:
> 
> > > Anyhow, including the process id in the Prof.* file's names sounds like a
> > > good idea.
> > 
> > Yes, it would be a good idea to do that *by default*. However, you also want
> > a way to override this choice, for use when testing the generation of profile data.
> 
> I disagree, I think the default should be unchanged for the reason that
> with it profiles can be viewed *without* having to specify extra options
> to mprof.
> 
> The runtime can have two new options, something like:
> 
>     --profile-suffix-name <name>
>     --profile-suffix-pid

I'd add another option:

    --profile-dir <dir>

This would be the directory, which the profile data is stored in. Then the
current working directory wouldn't be cluttered. Especially if we get the
three files for every forked process.

> which would use <name> or the process id respectively as a suffix on the
> various Prof.* files. (Actually, the deep profiler has the same issue
> with programs that fork, whatever solution we use with mprof should be
> applied to it as well.)
> 
> For convenience, mprof should get a new option that allows the profile
> suffix to be specified with one option rather than specifying -D, -C, -P
> separately.

Or let the user specify (any) one of the three files. mprof would recognize
the file (by name) and load all three.

> > We could use either MERCURY_OPTIONS, or a new, purpose-specific environment
> > variable.
> 
> If we use MERCURY_OPTIONS, then programs like Volkers' could set the new
> option at compile time via the --runtime-flags option.


Bye,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20230321/6e67b0a6/attachment-0001.sig>