[m-rev.] for post-commit review: --deep-std-name

[Zoltan Somogyi]

On Mon, 14 Oct 2024 02:02:27 +0200 (CEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > (It would be nice to have a [Reload] command, but this works.)
> 
> I will have a look at that. We could even have *two* reload commands:
> 
> - one that reloads the file with the same name as the profile now displayed, and

I just had a look. It seems that we *already* have this command in the usual menu,
just called "Restart" instead of "Reload". How does the existing "Restart" action
differ from the "Reload" action you want?

I am guessing that the answer may be "it loads the new version of the profiling data file,
but takes me back to the initial menu, instead of leaving me looking at the
procedure/clique/whatever I am now looking at". That is a valid concern,
but one that is orthogonal to the issue of what the data file is named.
Instead, it has to do with how the current page is identified.

When you are looking at e.g. the profile of a procedure, the deep profiler
now identifies that page by using an integer that is effectively a serial
number. If the procedure you are looking at is e.g. the 1234th proc
in the data file, it will have 1234 as its id. If the new profile is derived
from a program version that adds and/or deletes procedures, the
same procedure may have a different serial number in that version.
Displaying the procedure with id 1234 in the reloaded profile
would therefore be a bad idea, which is why we currently go back
to the main menu after a reload.

However, another possible fix for this would be for the page of
a procedure to be identified by the *name* of the procedure,
not its serial number. If you are on such a page, we could have
the profiler *stay on the page of that same procedure* after
a restart.

Doing something similar in cases where before the start,
the profiler was showing the page of a clique would be *much*
harder. This is because cliques exist only at runtime; they don't
have compile-time names. We *could* try to construct an id for them
from the call stack, the path taken from main to the current clique's
entry call, but this won't work in general, because in general, the
resulting "id" won't be unique. This is because if procedure P has
two or more call sites that both call Q, we don't know which one
the programmer means. We could try to identify the call site
by line number or the "goal path" of the call site within P, but
the update to the program could affect either or both. I am guessing
that when you did quit/back/refresh, this happened to not be a problem,
but a programmatic solution has to be more robust.

Peter: *besides* this issue of "a restart takes me back to the top menu",
is there any other difference between what you want and what
the existing "Restart" button gives you?

Zoltan.