tracing
flamegraph
Our great sponsors
tracing | flamegraph | |
---|---|---|
52 | 47 | |
4,919 | 4,241 | |
2.9% | 2.4% | |
8.1 | 7.4 | |
6 days ago | 8 days ago | |
Rust | Rust | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
tracing
-
Decrusting the tracing crate [video] by Jon Gjengset
The video description is as follows:
In this stream, we peel back the crust on the tracing crate — https://github.com/tokio-rs/tracing/ — and explore its interface, structure, and mechanisms. We talk about spans, events, their attributes and fields, and how to think about them in async code. We also dig into what subscribers are, how they pick up events, and how you can construct your own subscribers through the layer abstraction. For more details about tracing, see https://docs.rs/tracing/latest/tracing/.
-
Vendor lock-in is in the small details
> What's been your biggest issues around ergonomics/amenities for OpenTelemetry?
I can't speak generally, but in the Rust ecosystem the various crates don't play well together. Here's one example: <https://github.com/tokio-rs/tracing/issues/2648> There are four crates involved (tracing-attributes, tracing-opentelemetry, opentelemetry, and opentelemetry-datadog) and none of them fit properly into any of the others.
-
Grimoire - A recipe management application.
The tracing (logging) mechanism in an asynchronous codebase (tracing).
-
How easy is it to swap out your async runtime?
Tracing is Tokio's alternative for async code.
-
Hey Rustaceans! Got a question? Ask here (27/2023)!
At a technical level, in Rust, both [tracing]https://crates.io/crates/tracing) and log are entire ecosystems (though for the latter at least there's also third party logging frameworks), and there's at least a bridge from log to tracing.
-
How can I write a tracing subscriber that saves to a database?
I am using https://github.com/tokio-rs/tracing for logging purposes in my application. I would like to develop a feature wherein logs should be saved to a database table (via sea-orm). Something similar is this, but it does not solve my needs fully.
-
A locking war story
I've used the tracing infrastructure with tracing_flame to profile some hot paths in async code: https://github.com/tokio-rs/tracing/tree/master/tracing-flame
-
I was wrong about rust
Oh nice! IIRC when I checked, it was the Unicode tables that smashed the code size. I recently hit the same issue with the tracing crate, where a crate feature (for env var filtering) pulled in regex and my binary was suddenly 1MB bigger.
-
Debugging and profiling embedded applications.
I know about tools such as tracing, jaeger or tracy. While having a complete tracing could be a potential solution, these tools don't work with no_std.
-
Custom Axum Logging for Routes?
tracing by itself only outputs log data, you need to consume them in a subscriber, the tracing-subscriber crate exists for this. (example)
flamegraph
-
Rust Tooling: 8 tools that will increase your productivity
You can install cargo-flamegraph with cargo install flamegraph. There are some underlying requirements to be able to use cargo-flamegraph; you will want to take a look at the repo here to make sure you have the right dependencies.
-
Need help making sense of these benchmark results
I tried to diagnose the issue with flamegraph, but unfortunately the flamegraph didn't show anything beyond the next call for some reason
-
Why is my code so slow ? advent of code 2022, day 16 (basic graph stuff)
having some tools to identify slowness origins (flamegraph is one... but not sure it's the way to go)
-
why is my code so slow ? advent of code 2023, day 16 (basic graph stuff)
I'm currently implementing a solution for the first part of the day 16. It work but it is really slow... I'd like to : - understand why - having some tools to identify slowness origins (flamegraph is one... but not sure it's the way to go) - eventually have some clue/solution/idea - have general feedback on what in my "coding style" is not appropriate for rust (I come from java/kotlin/ts even if I've already coded a bit in c/c++) : for example I love iterator & sequence but i feel they are not really suited to overuse in rust (mostly because of async & result).
-
how expensive is an operation?
Use a profiler. Flamegraph is a good way to visualise profiler output. This lets you identify which functions are taking up a large amount of time - and hence helps you identify where to focus your optimisation efforts.
-
Slow Rust Redis
You tried trying to see what takes the most time under load via flames? https://github.com/flamegraph-rs/flamegraph
- making a virtual machine in rust
-
Need help with rust performance
Well, in cases like that the answer is straight forward, use a profiler like https://github.com/flamegraph-rs/flamegraph
-
superdiff - a way to find similar code blocks in projects (comments appreciated)
I don't see any obvious problems with your algorithm. I've had luck using cargo-flamegraph to identify the slow parts of my code. That's going to show you which parts to focus on improving the performance of!
-
Data-driven performance optimization with Rust and Miri
From the readme of cargo flamegraph:
What are some alternatives?
log4rs - A highly configurable logging framework for Rust
cargo-flamegraph - Easy flamegraphs for Rust projects and everything else, without Perl or pipes <3
slog - Structured, contextual, extensible, composable logging for Rust
tensorflow_macos - TensorFlow for macOS 11.0+ accelerated using Apple's ML Compute framework.
env_logger - A logging implementation for `log` which is configured via an environment variable.
hashbrown - Rust port of Google's SwissTable hash map
log - Logging implementation for Rust
heaptrack - A heap memory profiler for Linux
opentelemetry-rust - The Rust OpenTelemetry implementation
snmalloc-rs - rust bindings of snmalloc
vector - A high-performance observability data pipeline.
bcc - BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more