2 pointsby YuyuZha06 hours ago1 comment
  • YuyuZha05 hours ago
    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.