CLI tool
jonhoo/inferno avatar
jonhoo/inferno

Inferno: a Rust port of Brendan Gregg's FlameGraph toolkit

A Rust port of FlameGraph

2,171 stars163 forksRustNOASSERTION

At a glance

What is it?
A Rust rewrite of the stack collapsing and plotting parts of FlameGraph, roughly twenty times faster than the Perl originals, usable as a library or as three binaries.
Who is it for?
Inferno exists for one reason: collapsing large profiler output is the slow part of producing a flame graph, and the Perl scripts it replaces were the bottleneck. The rewrite keeps the same folded stack format as the original, so the two are drop-in compatible in the middle of the pipeline, and the criterion benchmarks in `benches/` mean a regression has somewhere to show up.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 81 days ago.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 7, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A partial port, aimed squarely at the slow step

Inferno is a port of parts of Brendan Gregg's FlameGraph toolkit to Rust, with the stated aim of improving the performance of the original tools. The README is specific about which part: the primary focus is speeding up the `stackcollapse-*` tools that process profiler output into the folded format the `flamegraph` plotting tool expects.

That framing is more informative than a generic rewrite claim, because FlameGraph is a multi-stage pipeline and not every stage is equally slow. Collapsing raw profiler samples into folded stacks is the stage that runs over the entire dataset, so it is where the twenty-fold difference comes from.

The README gives the headline numbers directly: `inferno-collapse-perf` is roughly twenty times faster than `stackcollapse-perf.pl`, and `inferno-collapse-dtrace` roughly twenty times faster than `stackcollapse.pl`. The sample collapser is quoted at about ten times. The comparison is reproducible, since running it means running `./compare.sh` with `hyperfine` installed and the submodules checked out.

It has 2,174 stars and 162 forks, is not archived, and the last push was on 2026-07-18. There are no tagged releases listed on the repository, so the version to track is in `Cargo.toml`: 0.12.8, on edition 2021 with a declared minimum Rust of 1.71.0.

From profiler output to an SVG in three commands

The workflow is short enough to describe completely. Build your application in release mode with debug symbols, run a profiler to collect samples, pass the output through the matching collapser, then feed the folded file to the plotting binary:

console
$ perf script | inferno-collapse-perf > stacks.folded
$ cat stacks.folded | inferno-flamegraph > flamegraph.svg

The two collapsers are platform specific. `inferno-collapse-perf` handles Linux `perf` output and `inferno-collapse-dtrace` handles DTrace output, which in practice means macOS. There is also `inferno-collapse-guess`, which the README says should work on both perf and DTrace samples, useful when you do not know what you are looking at.

On Linux you will likely need to relax a kernel setting before `perf` will give you anything. The README documents exactly which one:

console
$ echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid

That is a genuine practical step rather than an aside, since the default value on many distributions will produce an empty profile with a confusing error. The README points at Brendan Gregg's CPU Flame Graphs page for fuller profiler instructions, which is the right place to go for the surrounding process.

A crate as well as a set of binaries

Inferno is usable as a library through the `inferno` crate on docs.rs, which lets you collapse stacks and produce flame graphs without going through the command line. The README names the intended consumer: external Rust tools, specifically `cargo-flamegraph`, which handles much of the surrounding infrastructure.

That is the more interesting half of the project, because it means the performance work can be reused rather than reimplemented. A tool that wants to profile itself does not have to shell out and parse SVG.

The `Cargo.toml` features section shows how carefully the crate is factored for different consumers. The default features are `cli`, `multithreaded` and `nameattr`. `cli` pulls in `clap` and `env_logger`, so a library consumer that does not want the command line can drop it. `multithreaded` pulls in `dashmap` plus the crossbeam utilities and channel crates, which is where the collapsing speed comes from. `nameattr` pulls in `indexmap`, which preserves insertion order for frame names so output stays deterministic.

That last point is the kind of detail that separates a rewrite that is actually usable from one that only benchmarks well. Deterministic output is what makes the golden files in `tests/` and the criterion baselines meaningful.

Benchmarks that make regressions visible

The project includes criterion benchmarks in `benches/`, and criterion saves results under `target/criterion/`, which the README explains is what lets it recognise performance changes over time. The stated goal is making regressions easy to detect while fixing bugs and making improvements.

The published results are given for two machines, which is unusually generous documentation. On an AMD Ryzen 5 2600X desktop, `collapse/perf/1` runs in about 16.4 ms at roughly 182 MiB/s, and scaling to twelve cores brings the time down to about 4.8 ms at around 620 MiB/s. On an Intel Core i7-8650U laptop the single-threaded numbers are close but slightly lower, and eight cores give about 6.2 ms at roughly 486 MiB/s.

Note that the flame graph plotting stage is nowhere near as parallel: about 16 ms at roughly 38 MiB/s on the desktop, essentially unchanged between machines. That matches the README's framing, since the plotting step is not the target of the optimisation work.

The multithreading result is the interesting one. A little over three times the throughput from one thread to twelve is not linear scaling, which is what you would expect from a stage with shared state and channel overhead rather than embarrassingly parallel work.

The licence question deserves a careful read

The README states that Inferno is a port of Brendan Gregg's original FlameGraph project, written in Perl, and owes its existence and essentially all of its functionality to that project. Like FlameGraph itself, Inferno is licensed under the CDDL 1.0, and the README links the specific FlameGraph commit it follows.

`Cargo.toml` agrees, declaring `license = "CDDL-1.0"`. That is the authoritative field for Rust tooling, and it is also what `cargo` and `cargo deny` will read.

The repository's detected licence is recorded as unknown, however, rather than as CDDL-1.0. In practice this means tooling that relies on licence detection from the repository rather than the manifest will not find a match. The substantive answer is stated consistently in two places, but if you are shipping Inferno inside a product, the discrepancy is worth raising with the author so it resolves cleanly rather than leaving your own compliance review with an ambiguity.

The attribution detail is worth keeping in mind more broadly. FlameGraph is a widely used tool, and CDDL-1.0 is a file-level copyleft licence, which behaves differently from GPL at the repository level. The README's pointer to the upstream commit is there for a reason.

Built in public, one stream at a time

The README notes that Inferno is developed in part through live coding sessions, with a link to a YouTube playlist. That is a small detail that says a lot about how the project arrived at where it is, and it is the kind of transparency that makes a rewrite auditable: you can watch the reasoning rather than only read the diff.

The repository tree is compact and easy to navigate. `src/` holds the implementation, `benches/` the criterion benchmarks, `tests/` the golden file suite with test data under `tests/data/`, and there is a `flamegraph` entry, which is the git submodule pointing at the original Perl toolkit. That submodule is why the README instructs you to check out submodules before running `./compare.sh`.

There is also a `CHANGELOG.md` and no release tags in the repository listing, so the changelog rather than the tag list is where the history lives. Development uses `once_cell` in several places for lazily initialised shared state, and `ahash` for hashing, both reasonable choices for a tool whose inner loop is accumulating string keys into a map.

One detail in `Cargo.toml` is worth flagging if you profile Inferno itself: the release profile sets `strip = true`, with a comment explaining that to use a flame graph on Inferno binaries you should comment that line out and uncomment `debug = true`.

Editorial conclusion

Inferno exists for one reason: collapsing large profiler output is the slow part of producing a flame graph, and the Perl scripts it replaces were the bottleneck. The rewrite keeps the same folded stack format as the original, so the two are drop-in compatible in the middle of the pipeline, and the criterion benchmarks in `benches/` mean a regression has somewhere to show up. Licence handling deserves a second look before you vendor it: the repository is recorded as having no detected licence while the README and `Cargo.toml` both state CDDL-1.0, a discrepancy worth resolving with the author rather than assuming. Start with `inferno-collapse-perf`, and read the licensing section of the README in full before shipping it in a product.

Frequently asked questions

What is Inferno used for in profiling?

It replaces the slow collapsing stage of Brendan Gregg's FlameGraph pipeline. You pipe raw profiler output from `perf` or DTrace into `inferno-collapse-perf` or `inferno-collapse-dtrace` to produce a folded stack file, then pass that to `inferno-flamegraph` to render the SVG.

How much faster is Inferno than the Perl stackcollapse scripts?

The README reports roughly twenty times faster for the perf and dtrace collapsers compared with `stackcollapse-perf.pl` and `stackcollapse.pl`, and about ten times for the sample collapser. You can reproduce the comparison by running `./compare.sh`, which needs `hyperfine` and the checked out submodules.

Can I use Inferno as a Rust library?

Yes. The `inferno` crate is documented on docs.rs and exposes collapsing and flame graph generation without going through the command line, which is what tools such as `cargo-flamegraph` use. The crate has cargo features, so a library consumer can drop the default `cli` feature along with `clap` and `env_logger`.

What licence is Inferno under?

The README states CDDL 1.0, following the original FlameGraph project which it ports, and `Cargo.toml` declares `license = "CDDL-1.0"`. The repository's detected licence shows as unknown, so if you need to ship it, confirm the position with the author rather than relying on automated detection.

Official sources

  1. Issues
  2. jonhoo/inferno on GitHub
  3. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/jonhoo-inferno.svg)](https://hysenlabs.com/projects/jonhoo-inferno)