-
Notifications
You must be signed in to change notification settings - Fork 291
Improve displayed names in profiles #5861
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Use the 'original reference map' to translate created variables back to their references, so that the reference names can be pretty printed. This should yield their actual codebase names.
|
Looks like some type errors at build time |
In the lambda floating path, the variables wasn't been added to the unfresh variable set, so the same variable could be chosen multiple times erroneously.
Doesn't do anything interesting. This is just trying to make sure it isn't completely broken.
|
Fabio noticed a bug that I fixed in d73c.... Ran base test afterwards and all passed. |
Previously you would only get floated names for newly loaded definitions from the codebase, so profiling anything that was already loaded would just show hashes. Now we store names for everything we've loaded, like we do with references and whatnot. This is also less awkward than the extra result for the floated names from various functions.
|
I don't really understand the CI failures. It looks like it's complaining about the output for profiling commands in the help transcript. But I didn't change that. Is this a 'needs to merge with trunk' problem? Edit: nevermind, I reran the wrong transcripts. Still not sure how it was this PR that failed them. |
|
Sorry about the CI failures, it's something that changed nondeterministically in trunk. |
This PR modifies some of the compilation process to keep track of names for floated terms. These names are then fed into the profile rendering so that you see more comprehensible call sites, rather than just opaque hash prefixes.
As an example, the code:
produces profiling output like this:
The
$separator was chosen to avoid conflicting with multi-part namespaces, which could show up in the profile output.The remaining hash is the 'watch expression' from the unison file, which has no name.