Truncate certain fields in the UI. #74
Labels
S-feature
Severity: feature. This is adding a new feature.
Comments
hawkw
added a commit
that referenced
this issue
Aug 4, 2021
This branch updates the console to truncate fields named `spawn.location` when formatting fields on task spans, if the field's value is a path in the Cargo registry. Paths in the Cargo registry tend to look like this: ``` /home/eliza/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.9.0/src/runtime/basic_scheduler.rs:157:24 ``` We perform the truncation using a regular expression matching strings beginning with a `/` and accepting up to the string `/.cargo/registry/src`, followed by one additional path segment for the `github.com-<SHA>` part. The first match found in the string is replaced with the string `<cargo>`, so that it's clear the path is in the Cargo registry. This could, alternatively, have been implemented by parsing the paths to a `std::path::Path` and actually inspecting path segments. This might be more *semantically* correct than using a regex. However, the issue here is that the paths in the `spawn.location` field are generated in the environment where the instrumented program is _compiled_, rather than in the environment where the console application is running. This might, for example, be on an OS with a different path separator, and `std::path::Path` defaults to using the system's path separator. We could work around this, theoretically, but the regex seemed much simpler. Closes #74
hawkw
added a commit
that referenced
this issue
Aug 4, 2021
This branch updates the console to truncate fields named `spawn.location` when formatting fields on task spans, if the field's value is a path in the Cargo registry. Paths in the Cargo registry tend to look like this: ``` /home/eliza/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.9.0/src/runtime/basic_scheduler.rs:157:24 ``` We perform the truncation using a regular expression matching strings beginning with a `/` and accepting up to the string `/.cargo/registry/src`, followed by one additional path segment for the `github.com-<SHA>` part. The first match found in the string is replaced with the string `<cargo>`, so that it's clear the path is in the Cargo registry. This could, alternatively, have been implemented by parsing the paths to a `std::path::Path` and actually inspecting path segments. This might be more *semantically* correct than using a regex. However, the issue here is that the paths in the `spawn.location` field are generated in the environment where the instrumented program is _compiled_, rather than in the environment where the console application is running. This might, for example, be on an OS with a different path separator, and `std::path::Path` defaults to using the system's path separator. We could work around this, theoretically, but the regex seemed much simpler. ### Before:  ### After:  (note the `spawn.location` fields from `hyper`). Closes #74
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Certain fields that are displayed by the UI -- currently/specifically
spawn.location-- can be exceedingly long to the point where most of the value is effectively noise, or even worse, it pushes other fields out of the viewport entirely.There should be a way to configure some sort of transformation for field data such that we can describe exactly how we want that field to look in the main UI view, vs the raw value itself.
As an example, right now
spawn.locationshows the file/line combination for where a task was spawned from. When the spawn location is in a file relative to the binary being instrumented, you typically end up with a relatively short string, such assrc/foo/bar/mod.rs:32. When the spawn location is in another crate, however, such as a dependency pulled in by Cargo, you end up with the absolute path, such as/Users/tobz/.cargo/github.com-d121af1a167ef/hyper-0.14.11/src/common/exec.rs:12. Half of that path is effectively useless information: all we really need to know that it came from Hyper is to be able to seehyper-0.14.11/src/common/exec.rs:12.As an example of how we might deal with this field specifically, the proposed transformation code may split the path such that it looks for common ancestors -- such as
.cargo-- and removes everything before the crate name. It could, alternatively or in addition, also collapse the string in a manner similar to Java's compressed classpaths in stack traces: changingorg.foo.bar.something.MyClasstoo.f.b.something.MyClass, where we might collapse the aforementioned absolute path to/U/t/./g/h/src/common/exec.rs.The text was updated successfully, but these errors were encountered: