Repository navigation
Conversation
Ran the pooled benchmark on Corretto 8.0.472 / 11.0.29 / 21.0.9 (same
machine, same JMH config) to put hard numbers behind the older-JDK
speedup claim. Two findings worth pinning:
* fast-printf's varargs path is JDK-version-invariant (214 → 216 →
221 ns) — the library owns its performance regardless of Hotspot
improvements.
* The Args no-boxing builder is the one fast-printf path that
materially improves with JDK version (326 → 247 ns); JDK 11+'s
better small-method inlining helps its chained calls.
* String.format is the big mover: 1450 → 404 ns from JDK 8 to JDK 21
(3.6× faster). That alone explains the shrinking relative speedup
— fast-printf didn't slow down, the JDK closed the gap.
Speedup vs String.format on this workload:
JDK 8: varargs 6.77×, TL cache 5.94×
JDK 11: varargs 4.95×, TL cache 5.38×
JDK 21: varargs 1.83×, TL cache 2.17×
README:
- Key Features bullet now lists concrete per-JDK ratios instead of
"up to 4×".
- Performance section gains a "Cross-JDK regression" sub-section with
the full table and the two storylines.
CommonUsageBenchmark Javadoc:
- Single-JDK result block replaced with a per-JDK regression table.
- Allocation profile is JDK-21-only (JMH's gc profiler doesn't yield
reliable B/op numbers on Hotspot 8).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
JDK 17 (Corretto 17.0.17) numbers, same machine, same JMH config:
fastPrintf varargs 199.73 ±11.6 ns ( 696 B/op)
fastPrintf Args builder 247.23 ± 4.9 ns ( 592 B/op)
fastPrintf TL cache 196.83 ±37.4 ns ( 608 B/op)
String.format 885.77 ±65.6 ns (2776 B/op)
Speedup vs String.format: varargs 4.43×, TL cache 4.50×.
The interesting JDK 17 data point: String.format throughput is already
improving (1069 → 886 ns vs JDK 11) but allocation is the heaviest of
any JDK we measured (2776 B/op). The big drop to 1280 B/op happens in
JDK 21 with the Formatter rewrite.
README:
- Cross-JDK regression table gains a JDK 17 column.
- Key Features bullet now reads "~4.5× faster on JDK 17" alongside
the other version-specific ratios.
CommonUsageBenchmark Javadoc:
- Result table widened to 4 JDK columns.
- Allocation profile now shown for JDK 11+, with JDK 17's outlier
jdkPrintf allocation called out explicitly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The README had grown a redundant trio of value-prop sections (Quick Start
→ Key Features → When to use) and the "Performance (JDK 21)" heading was
misleading after the cross-JDK regression landed. Reflow:
* New top-of-page lead paragraph that front-loads the value prop
("1.8–6.8× faster, ~50% less garbage") instead of two near-duplicate
intro paragraphs.
* "Key Features" + "When to use fast-printf" merged into a single
"Why fast-printf?" section.
* "Performance (JDK 21)" → "Performance"; leads with an SVG bar chart
(docs/perf-cross-jdk.svg), then the cross-JDK table, then the JDK 21
allocation profile, then the design-trade-off notes for Args builder
and ThreadLocal cache.
* "Advanced: JDK 21 Floating-Point on Java 8" was an orphan single-
paragraph section — folded into "How It Works" as a subsection where
it belongs.
* "API Reference" → "Format String Reference" (more descriptive).
* "Key Differences from String.format" → "Differences from String.format".
* TOC updated to match the new ordering.
The chart is a hand-rolled SVG (760×470, three series across four JDK
groups, with value labels). Pure declarative SVG, no scripts — renders
correctly on github.com, in IDE previews, and on Maven Central's README
display.
Net diff: -124 / +107 (≈17 lines shorter overall) plus the new SVG.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #37 +/- ##
=========================================
Coverage 95.85% 95.85%
Complexity 1094 1094
=========================================
Files 57 57
Lines 2122 2122
Branches 342 342
=========================================
Hits 2034 2034
Misses 41 41
Partials 47 47 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.