Viktor Vilhelm Sonesten
Viktor Vilhelm Sonesten
Additional inspiration: https://github.com/probe-rs/probe-rs/blob/master/.github/workflows/release.yml
Flame charts are more applicable because a flame graph does not have time on the x-axis. Can be found in [Firefox](https://developer.mozilla.org/en-US/docs/Tools/Performance/Flame_Chart) and [Chrome](https://developer.chrome.com/docs/devtools/evaluate-performance/reference/).
To be able to exploit existing tools we'd need to be able to generate `perf` or [DTrace](https://www.joyent.com/dtrace) output.
[orbuculum](https://github.com/orbcode/orbuculum) has some graphical tools we may be able to exploit. Specifically `orbtop` and `orbstat`.
After a brief look at [hotspot](https://github.com/KDAB/hotspot) and similar tools, it seems like the most ubiquitous profilers are based upon a thread-based execution model with PC samples as the input data....
Some experimental work with Python plotting has been done in 0a8490c355e808c8b83261ce3d48d567f9e3396d.
#113 is an issue here.
Hints that are buried beneath any level of abstraction from RTICScopeError are not propagated (`PACError` works, for example). Some type info is lost somewhere.
Hints for hinted errors are now printed as expected. As long as we don't decorate relevant calls with a `context` it will stay that way. Reverting to only printing top-level...
We can `Chain` over an error by using the `std` feature in `anyhow`. But if we do that on `RTICScopeError` we get a laundry list of traits we need to...