Performance

The suite pits gotmpl4j against four of the most-used JVM template engines, plus Go itself as a cross-runtime reference:

The workload mirrors the canonical mbosecke/template-benchmark "stocks" table: render a list of N stock rows, each with a loop, a gain/loss if/else conditional, six field accesses, and two floating-point values (price, percentage ratio). gotmpl4j and Go share the same table.gotmpl, so that column is a true like-for-like across runtimes.

Render throughput in ops/µs — higher is better. Templates are pre-parsed in @Setup, so this measures the hot render path, not compile cost.

The other JVM engines can’t express gotmpl4j’s distinctive surface — Sprig functions, pipelines, control flow, printf, template composition. But its reference implementation can: Go text/template + Masterminds/sprig is exactly what gotmpl4j re-implements, so the FeatureBenchmark suite renders the same templates and data through both and reports gotmpl4j against native Go+Sprig — the most direct apples-to-apples there is.

gotmpl4j out-throughputs native Go+Sprig on every feature workload — 6–16× across the Sprig and control-flow surface (the JVM JIT versus the Go interpreter, the same dynamic as the table), and now ahead on printf too. printf used to be the one place Go won (~2×); pre-compiling its rewrite patterns (a per-call Pattern.compile was the cost) cut that allocation by two-thirds and lifted throughput +57 %, flipping it from a ~2× loss to a ~1.2× win. (As with the table, the Go column writes to io.Discard while gotmpl4j materialises a String, so Go does strictly less work — yet still loses on all six.)

Render is the hot path (it runs per request), but a template is also parsed once — helm template-style one-shot workloads pay it on every invocation. ParseBenchmark measures that cold parse across the same engines, using the identical table template each renders. Each engine is made to re-parse on every call (Mustache via a fresh DefaultMustacheFactory, Pebble via a cacheActive(false) engine), so the number is a real parse, not a cached-template lookup. Thymeleaf is omitted — its API doesn’t separate parse from render.

The ordering tracks grammar richness, not engine quality: Mustache parses fastest because it has almost nothing to parse (logic-less tags), while gotmpl4j parses Go’s entire action grammar. gotmpl4j parses ~3× faster than FreeMarker (the other full-feature engine) and slower than the leaner Mustache/Pebble. Parse is a one-time cost amortised across every render — the render tables above are the fair head-to-head. gotmpl4j is also the heaviest table-parser on allocation (a Token object plus a substring value per token, inherent to the token-list model); the #96/#97 work trimmed the secondary allocation, and the remaining bulk would need an offset-based token redesign.

A second benchmark, gotmpl4jParseLargeChart, parses a Helm-chart-shaped template (multi-KB of YAML, hundreds of actions) at 1,169 µs/op and 1.25 MB/op — the workload where the #96 lexer fix turned an O(n²) scan into a ~5× speedup. See Optimization history → Parse path below.

The engines above are all interpreters (they walk an AST at render time). A separate tier of compiled engines — Rocker, JTE, JStachio, and others — generate Java bytecode from templates and therefore sit a notch above every interpreter measured here, gotmpl4j included. For that broader landscape see the canonical mbosecke/template-benchmark and the agentgt fork (which adds JTE and JStachio).

gotmpl4j’s niche is Go-template compatibility, not beating a code generator: if you need to render Helm-/Hugo-style text/template + Sprig templates on the JVM, gotmpl4j does it at mainstream-interpreter speed.

The benchmarks live in the (unpublished) gotmpl4j-benchmarks module:

The interpreter has been profiled with jvmlens (JFR → LLM-ready hot-path/allocation summary) and tuned along the way. The floatString row below is written up step-by-step — profile → fix → prove byte-identical → guard — as the jvmlens floatString case study, and the inline JMH keep=/baseline= A/B loop used here is documented on the jvmlens usage page.

Cumulatively, per-render allocation on the table workload dropped by roughly two-thirds versus the original baseline (n=1000: 2.05 MB → 0.64 MB, −69%). The wins came from caching the per-class property accessor map (amortising JavaBeans introspection across renders), rewriting GoFmt.floatString to format directly from Double.toString digits into a presized builder with no intermediate substrings, reusing per-thread scratch buffers for that formatting, and replacing the synchronized StringWriter output sink with an unsynchronized StringBuilder. Each was found and verified with jvmlens plus a multi-fork JMH gc.alloc.rate.norm A/B.