Rust forum post benchmarks decimal crates for performance and tradeoffs

WuBingzheng’s June 17 forum post does something more useful than announce another library tweak: it turns Rust decimal selection into a working guide for real code. The post, published at 11:33 a.m. in The Rust Programming Language Forum’s tutorials category, says the author compared several decimal crates, benchmarked them extensively, and invited more suggestions for the set. That matters because decimal math in Rust is rarely about one neat API surface; it is about the balance between exactness, performance, serialization, and how much friction you can tolerate in a project.

What this comparison is really trying to solve

Decimal crates are one of those Rust decisions that look simple until the workload gets specific. If you are moving money, tracking prices, or preserving base-10 values for display and storage, the wrong crate can give you awkward rounding, awkward formatting, or a performance profile that only looks good in a microbenchmark. WuBingzheng’s comparison is valuable because it treats the choice as an engineering tradeoff, not a popularity contest.

That framing also explains why the post is backed by a GitHub repository called `decimal-crates-comparison`. A living benchmark set is more useful than a one-off writeup because decimal use cases tend to differ wildly: some projects are mostly arithmetic, others are mostly parsing and formatting, and still others care more about no-std support or serde integration than raw speed. The forum post is built to expand over time, which makes it a reference point rather than a verdict.

The crates are not interchangeable

The comparison makes most sense when you look at what each crate is trying to optimize. `rust_decimal` is the familiar fixed-precision option, and docs.rs describes it as suitable for financial calculations. It uses a 96-bit integer, a scaling factor, and a sign bit, and it preserves trailing zeros in string form, which is the sort of detail that matters when a decimal is not just a number but part of a presentation or accounting workflow.

`bigdecimal` takes a different route. Instead of fixed-precision storage, it uses `BigInt` plus a 64-bit integer to track decimal position, which gives it arbitrary-precision behavior with a different set of limits and costs. Its documentation notes that precision is effectively limited by that 64-bit scale representation, so even the “big” in big decimal comes with implementation boundaries that matter once your input sizes or exponent ranges get unusual.

Then there is `primitive_fixed_point_decimal`, which pushes toward a different kind of practicality. It supports serde, no-std, and no-alloc, and it is designed to use the underlying integer bits more fully than `rust_decimal`. That makes it especially interesting when your crate choice is shaped by deployment constraints as much as by arithmetic semantics.

Why benchmarks matter more than the headline API

The reason this kind of post gets attention in Rust is that decimal performance changes shape depending on where the work happens. A crate that looks excellent in pure arithmetic can become a worse fit once you add string parsing, formatting, and real application flow. That is exactly the kind of tradeoff a comparison article can expose better than a release note ever could.

A useful historical clue comes from WuBingzheng’s February 2026 benchmark post, which compared `rust_decimal` and `primitive_fixed_point_decimal`. There was also a May 2026 benchmark on the forum that compared eight decimal crates, including `ancdec`, `rust_decimal`, `fastnum`, `fixed-num`, and `bigdecimal`. That earlier work found that a compile-time-fixed scale crate could be very fast on pure scalar operations but much slower once parsing and display were included, which is a reminder that end-to-end workflow often matters more than raw arithmetic speed.

How to pick a crate for common Rust workloads

If your project looks like a finance side project, `rust_decimal` is usually the first crate worth trying. Its fixed-precision model, financial positioning, and trailing-zero preservation make it easy to reason about when you want predictable decimal behavior without building your own representation rules. It is the most straightforward fit when correctness, human-readable output, and ergonomics matter more than squeezing every last cycle out of arithmetic.

If your app is serialization-heavy, `primitive_fixed_point_decimal` deserves a hard look, especially if no-std or no-alloc constraints are part of your environment. The serde support makes it feel more ready for data pipelines and structured interchange, while the lower-allocation design can help when memory behavior is as important as the numbers themselves. In a project that spends a lot of time moving decimals in and out of payloads, that combination may matter more than a small difference in bare math speed.

If you are building a performance-sensitive service, the main lesson is not “pick the fastest crate” but “measure the right path.” The May benchmark’s result about pure scalar speed versus parsing and display is the warning label here: a crate that wins arithmetic can still lose the application if input handling dominates. For that reason, benchmark your real request path before committing, and treat microbenchmarks as a clue, not a finish line.

For cases where the arithmetic range itself is the problem, `bigdecimal` remains the interesting option because it is built around arbitrary precision. That can be the right fit when you care less about compact representation and more about keeping decimal math broad enough for demanding calculations. It is not the same kind of tool as `rust_decimal`, and the comparison makes that difference impossible to miss.

• Choose `rust_decimal` when you want the most familiar financial-friendly fixed-precision path.
• Choose `primitive_fixed_point_decimal` when allocation behavior, serde, or no-std support is central.
• Choose `bigdecimal` when arbitrary precision is the priority and you can pay for it.
• Treat any pure arithmetic win as provisional until you test parsing, formatting, and serialization too.

A living benchmark, not a final verdict

The forum thread’s invitation for more crate suggestions is part of what makes the post useful. It signals that this is not a closed ranking but an evolving map of the decimal ecosystem, which is exactly what Rust users need in a space where crate design choices are tightly tied to workload shape. The commenter response on Lobsters, where one reader suggested the graph would benefit from a log scale, also shows that readers are engaging with the methodology, not just the headline winner.

That is the real value of WuBingzheng’s comparison: it gives the Rust community a way to talk about decimal crates as tools with different strengths instead of as brands competing for a single crown. For anyone choosing a decimal engine for money, data, or performance-sensitive code, that is the kind of guide that saves time before the first migration even begins.