Scope colors
kvark opened this issue · comments
Would it be reasonable to expose the colors in this crate?
It would enhance the tracy backend experience quite a bit. For example, in https://github.com/gfx-rs/wgpu-rs/discussions/879 we would mark every crate (gfx/wgpu/wgpu-rs) with a separate color.
https://github.com/davidwed/tracy#marking-zones describes the way to pass down colors in Tracy.
I like the feature idea and I would use it myself. That said, I do have similar feelings about this as another feature request from before: #3 (comment)
- Not all backends support this
- Some people won't take this crate as a dependency unless it stays very small and simple (the value this crate provides is greater if more crates use it)
- End-users can interface directly with their profiling crate of choice, so it's still possible for end-users to do this, even if this crate doesn't directly support it.
If we did it, what do you think the API should look like? Two approaches come to mind:
- Optionally pass a color into any scope!() or function!() procmacro
- Have some sort of push/pop mechanism using thread locals
The first approach is repetitive, but the second requires using thread locals which aren't free or async-friendly. Also, practically speaking, if multiple upstream crates hardcode their own colors for things, it might make the coloring less useful. Pushing/popping colors might help with this.
I understand the concern here and fully agree on it, in general.
In particular though, the API complexity increase appears to be small, and the backends that don't understand colors can just ignore it. So it seems feasible to introduce.
If we did it, what do you think the API should look like?
We need a mini-investigation on how the backends expose this, unless you already know :)
If we are talking about Tracy, then your first suggestion makes sense (just an extra optional parameter to the scoping macros).
- Optick does not expose anything in the C API, but has a lower-level API and a categories system with pre-defined colors. It may be possible to use the lower-level (maybe not intended as public?) existing API: https://github.com/bombomby/optick/blob/master/src/optick.h
- I think puffin always colors based on time spent. I imagine they would accept a PR allowing custom colors.
- Superluminal can optionally take a color on every event
- Tracy can optionally take a color on every event
- For tracing, we could add attributes or fields https://docs.rs/tracing/0.1.25/tracing/#recording-fields
It is probably possible to PR improvements to puffin and optick.
We would still need to decide on what the profiling API would look like:
- Optionally take a color in every scope
- Push/pop colors
- Some sort of category system (inspired by optick)
- This could potentially allow a top-level binary crate to configure colors for upstream libraries. The lookup would likely be a hashmap lookup the first time a scope is invoked. This could be an optional feature. It may be possible to have the category default to the crate name, and suggest a convention of [crate-name]::[category-name] for crates that want to define more. I don't know to what extent this can be automated within a macro
I don't plan to work on this myself at this time, but leaving it here for anyone who wants to pick it up. Happy to review PRs.
Thank you for the investigation!
I don't see how (2) push/pop approach is going to work. I want to have different layers of the stack using different colors, so it would force me to do a push -> marker -> pop at each stage, which is a waste. I.e. I will not be able to keep the pushed color for more than 1 scope anyway.
The approach with categories (3) sounds very interesting. I like the idea, but I imagine that it may not work out.
Both (1) and (3) would work for us.