Rust image-rs fast_blur gets up to 5.9x faster with integer math

Arthur Pastel found a very specific kind of Rust payoff in image-rs: the crate’s `fast_blur` path, one of the few places where image processing spend is concentrated in a hot inner loop, got as much as 5.9x faster on images with `u8` pixels. That is the sort of improvement that lands immediately for people shipping thumbnails, preview panes, asset pipelines, or server-side transformations, because it speeds up a named API path instead of waving at abstract throughput.

The change was not magic, just disciplined arithmetic. Pastel’s optimization replaced float-heavy blur work with integer accumulators, then cut out expensive per-pixel division by precomputing a reciprocal. In practice that means the loop does less work for every pixel that passes through it: a 64-bit multiply and right shift stand in for repeated division, and the CPU spends more time moving through image data and less time on arithmetic overhead. It is the classic Rust performance story where the gain comes from making the compiler’s job easier and the instruction mix cheaper, not from changing the feature users call.

That matters because `image` is the standard Rust crate for native image encoding, decoding, and basic manipulation, and `fast_blur` is already documented as the faster, less accurate alternative to `blur`. Its implementation follows Kovesi’s Fast Almost-Gaussian Filtering work from DICTA 2010, and the docs note that it assumes alpha pre-multiplication for images with non-constant alpha. In other words, this is not an obscure helper tucked away in a corner. It is a public, documented path that exists precisely for the cases where speed matters more than exact Gaussian fidelity.

The broader signal is that mature Rust crates still reward careful, local optimization when the code sits on a real hot path. That is especially true in image-rs, where `fast_blur` is already the kind of function people reach for when they want a blur that is good enough and quick. GitHub issues in the crate have pointed in the same direction, including a proposal to use `fast_blur` for `unsharpen` because the blur mask does not need to be perfect, plus notes that `fast_blur` and `blur` handle edges differently and that `fast_blur` had been slower than it should have been. Pastel’s result turns that long-running complaint into a concrete answer: the path that used to be easy to dismiss as benchmark theater now looks like a real lever for everyday Rust image workloads.