[m-users.] Grade for profiling

[Zoltan Somogyi]

2023-03-21 20:53 GMT+11:00 "Volker Wysk" <post at volker-wysk.de>:
> Am Dienstag, dem 21.03.2023 um 20:35 +1100 schrieb Zoltan Somogyi:
>> 2023-03-21 20:31 GMT+11:00 "Volker Wysk" <post at volker-wysk.de>:
>> > > That makes sense. The Prof.Decl file would be written when the program
>> > > starts up, and the Prof.Counts file is probably overwritten by each
>> > > process when it shuts down. Obviously, you may not get usable profiling
>> > > information then.
>> > 
>> > But I *have* got usable profiling information. At least it seems to me.
>> > (It's the first time I'm using a profiler.) This way I've found a
>> > performance bug, btw.
>> > 
>> > The processes I create with fork/exec, and the one forking, are all the same
>> > program. It's a command line option, which tells each child process what to
>> > do. Maybe that's the reason why I get usable profiling data.
>> 
>> Peter did not say you *definitely* wouldn't get usable data; he said
>> you *may* not get usable data. If Peter's overwriting theory is true
>> (I have not checked), then you get the profiling data from the last
>> process of your program to exit. This process *may* contain
>> a bottleneck that profiling can reveal, but  bottlenecks may exist
>> in the earlier-exiting processes as well.
> 
> 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.
We could use either MERCURY_OPTIONS, or a new, purpose-specific environment
variable.

Another needed change would be to write out all the Prof.* files at the end of execution
of each process (or something functionally equivalent), so that a profiled process that
does a fork associates (through the process id) its Counts and CallPair files with its Decl file,
whether or not it also does an exec.

Zoltan.