Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
tracing: change span naming to new console convention (#4042)
Currently, the per-task spans generated by Tokio's `tracing` feature have the span name "task" and the target "tokio::task". This is because the console subscriber identified tasks by looking specifically for the "tokio::task" target. In tokio-rs/console#41, it was proposed that the console change to a more generic system for identifying the spans that correspond to tasks, to allow recording tasks belonging to multiple runtime crates (e.g. an application that uses Tokio for async tasks and Rayon for CPU-bound tasks). PR tokio-rs/console#68 changed the console to track any spans "runtime.spawn", regardless of target (so that the target can be used to identify the runtime a task came from), with "tokio::task/task" tracked for backwards-compatibility with the current release version of tokio. This branch changes Tokio's span naming to the new convention. I also rearranged a couple fields so that the task's kind field always comes before the name and spawn location, since it's likely to be the shortest, and renamed the `function` field on blocking tasks to `fn`, for brevity's sake. Signed-off-by: Eliza Weisman <[email protected]>
- Loading branch information
d0305d5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possible performance regression was detected for benchmark 'sync_mpsc'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold
2
.send_large
62514
ns/iter (± 7191
)29641
ns/iter (± 1204
)2.11
This comment was automatically generated by workflow using github-action-benchmark.
CC: @tokio-rs/maintainers
d0305d5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I can't imagine any reason why this would impact the MPSC benchmark performance...this code is all
cfg
'd out entirely in the benchmarks, AFAIK?d0305d5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The benchmarks are really unstable and fail every four or five commits.