Hello HN,
I recently released FastPrintf, a drop-in replacement for String.format and java.util.Formatter designed for high-throughput/low-latency Java systems (logging, trading, serialization).
The Problem:
The standard Java formatters generate significant garbage (allocating Object[] for varargs, boxing primitives, and discarding internal char[] buffers). On legacy JDKs (8/11), the floating-point formatting is also slow due to older algorithms.
The Solution:
I re-implemented the printf spec from scratch with a focus on "Zero-Allocation" and glibc compatibility.
Key Technical Features:
Rope Data Structure: Instead of appending to a resizing StringBuilder, it constructs a lightweight tree (Seq) of views and literals. It uses a trampoline iterator to traverse the tree without recursion (avoiding StackOverflow) and renders the string in a single pass.
Schubfach Algorithm: I backported the Schubfach floating-point algorithm (used in newer JDKs) to Java. This means JDK 8 users get modern C++ speed for %f and %e formatting (up to 5x faster than native).
Zero-Boxing: It uses a "Traits" system and a custom Args builder to handle primitives directly, completely bypassing Object... varargs and auto-boxing.
AOT Compilation: Format strings are parsed once into a chain of appenders, removing parsing overhead from the hot path.
Benchmarks (JMH):
On a complex mixed-type format string:
FastPrintf: ~380 ns/op (Zero GC)
String.format: ~1235 ns/op (High allocation)
It is notably faster than a hand-written StringBuilder in specific "join" scenarios due to vectorized array copying thresholds in the Rope implementation.
License: GPLv2 + Classpath Exception (same as OpenJDK), so it's safe for commercial dependencies.
The code is heavily documented if you are interested in the internals of the Rope implementation or the floating-point math. I'd love to hear your feedback on the architecture.
YuyuZha0•1h ago