hotpath-rs

hotpath - Rust Performance, CPU & Memory Profiler

hotpath-rs is an easy-to-configure Rust performance profiler that shows exactly where your code spends time, burns CPU, and allocates memory.

It helps you distinguish between functions that are slow because they wait on I/O and those that are CPU-intensive. Instrument functions, channels, futures, streams, SQL queries, HTTP calls, and byte-level I/O to find bottlenecks and focus optimizations where they matter most. Get actionable insights into time, memory, and async data flow with minimal setup. Built-in support for Prometheus metrics and Grafana dashboards.

Try the TUI demo via SSH - no installation required:

ssh demo.hotpath.rs

Or let your own AI agent configure profiling in a repo:

cargo install hotpath
hotpath init --agent claude 

Explore the full documentation at hotpath.rs. See CONTRIBUTING.md for development setup and guidelines.

You can use it to produce one-off performance (timing, memory or CPU) reports:

inspect throughput and latency of network, file or compression I/O streams:

analyze SQL/HTTP calls performance with automatic source function attribution:

monitor throughput, performance and max queue depth of instrumented channels:

or use the live TUI dashboard to monitor real-time performance and async data flow metrics with debug info:

https://github.com/user-attachments/assets/2e890417-2b43-4b1b-8657-a5ef3b458153

Features

• Time, CPU & memory profiling - identify expensive functions, allocation hotspots, and investigate memory leaks.
• Async observability - futures, channels and streams.
• I/O monitoring - bytes, throughput, latency of any sync or async IO stream like files, TCP, or compression.
• SQL query profiling - query performance metrics for sqlx and Diesel.
• HTTP calls profiling - per-endpoint latency and error metrics for reqwest and ureq.
• HTTP server profiling - per-route response time and error metrics for axum.
• Concurrency metrics - Mutex/RwLock wait time and contention.
• Tokio runtime monitoring - workers, scheduling and queues.
• Prometheus & Grafana integration - export profiling metrics to your existing dashboards.
• Live TUI dashboard & static reports - real-time or one-off analysis.
• CI regression detection - benchmark every PR automatically.
• MCP server for AI agents - query profiling data in real time.
• Zero cost when disabled - fully feature-gated.

Getting Started

AI Setup (Recommended)

The quickest way to set up hotpath is to let an AI coding agent do it. Install the hotpath CLI and run init inside your project:

cargo install hotpath --version '^0.26'
hotpath init --agent claude # or --agent codex / --agent opencode

hotpath init downloads the hotpath_init agent skill from GitHub and starts an interactive Claude Code, Codex or OpenCode session with it as setup instructions. The agent inspects your project, adds the feature-gated dependency, instruments main and a starting set of functions, channels and locks, then verifies that everything compiles with profiling enabled and disabled. You review and approve each edit through the agent's regular permission prompts. Requires curl and the claude, codex or opencode CLI on PATH.

You can also use the skill directly, without the hotpath CLI: copy it to ~/.claude/skills/hotpath_init/SKILL.md and run /hotpath_init in a Claude Code session.

Manual installation

Add to your Cargo.toml:

[dependencies]
hotpath = "0.26"

[features]
hotpath = ["hotpath/hotpath"]
hotpath-cpu = ["hotpath/hotpath-cpu"]
hotpath-alloc = ["hotpath/hotpath-alloc"]
hotpath-prometheus = ["hotpath/hotpath-prometheus"]

This config ensures that the lib has no compile time or runtime overhead unless explicitly enabled via a hotpath feature. All the lib dependencies are optional (i.e. not compiled) and all macros are noop unless profiling is enabled.

Basic setup

You'll need only #[hotpath::main] and #[hotpath::measure] macros to get started:

…

Now, run your program with hotpath (and optionally hotpath-alloc features):

cargo run --features='hotpath,hotpath-alloc'

On exit it will print a report with timings, memory allocations and thread usage metrics:

…

Full documentation

See the full docs and advanced config tutorials at hotpath.rs.

Read the complete guide to profiling Rust applications - a comprehensive overview of debugging performance issues in Rust.

• Profiling modes - static reports vs live TUI dashboard
• Profiling overhead - per-operation instrumentation cost and time sampling
• Functions - measure execution time and memory allocations
• CPU profiling - attribute CPU samples to instrumented functions
• Threads - monitor threads usage
• Async Data Flow - monitor channels, streams, and futures
• Locks - track Mutex and RwLock wait and hold times
• SQL queries - profile query execution time for sqlx and Diesel
• HTTP requests - profile reqwest and ureq client calls per endpoint
• HTTP server (axum) - profile axum request latency and errors per route
• I/O tracing - monitor bytes, throughput and duration of TCP, Redis, and file operations
• Tokio Runtime - monitor Tokio runtime worker stats and task scheduling
• Debug & Metrics - track custom values with dbg!, val!, and gauge! macros
• Prometheus & Grafana - export metrics to Prometheus and build Grafana dashboards
• GitHub CI - automated benchmarking and regression detection in CI
• MCP Server - LLM integration via Model Context Protocol
• Cargo flamegraph alternatives - when to use hotpath vs sampling profilers like perf and samply
• Configuration - explore all config options

Waitlist

My long-term goal for hotpath-rs is to become the single place to understand all performance signals in a Rust application. From CPU and memory usage to locks, channels, and async execution, all the way up to SQL queries and HTTP/RPC calls.

I'm also building a hosted version that makes profiling reports easier to share, compare, and analyze across pull requests, deployments, and teams.

If that sounds useful, join the waitlist for early access:

https://hotpath.rs/#waitlist

Status

This project is under active development. Core public APIs are stable, but implementation details (JSON report formats, TUI/MCP internals, and advanced config options) may change between releases as the project evolves.