Trim per-query allocation in the statement build path

[zantvoort]

Problem

On short operations, statement building dominates Storm's per-operation allocation. Precise per-thread allocation counters over a warmed hot loop of a by-primary-key read (PostgreSQL, three-column entity) split as:

phase	B/op
builder chain (DSL objects)	1,623
build, i.e. SQL generation	8,016
full operation (execute + hydrate)	10,908
hand-written JDBC, entire operation	1,894

Roughly 73% of the operation's allocation happens in the build phase — about 6.4 KB per call beyond the builder chain — even though the compiled SQL itself is cached. JMH's allocation profiler shows the same pattern across every short workload, and the excess correlates with the small latency deltas to the leanest implementations on point operations (single-row read, projection, dynamic query, read-modify-update, create-then-amend): roughly 5–7 KB/op of additional allocation tracks a 4–17 µs/op gap.

Proposal

Profile the build path (template processing through SqlTemplateImpl.process and statement preparation) with allocation events and itemize the ~6.4 KB, then trim the dominant producers. Likely candidates, to be confirmed by measurement rather than assumption:

• per-call construction of compilation keys, element lists, and template fragments for templates whose compiled form is already cached;
• binder and parameter-list allocations that could be sized or reused for cached templates;
• intermediate string building in fragments that end up identical for every execution of the same template.

A win here lifts every short workload at once. Multi-row reads are unaffected: their per-row hydration already dominates and is competitive.

[zantvoort]

PR #296 lands the first pass: dialect reuse in query creation, SqlParser fast paths and marker guards, single-pass/BitSet parameter validation, per-processor unsafe-statement check, cached metamodel hash, and a cached query-builder provider. Build-phase allocation halved (8,016 → 4,031 B/op); singleRowById −34%, updateById −40%, multiStatement −39%, dynamic −13%.

Remaining tail, kept open here: per-call BindingSession/SqlImpl/parameter-list carriers, and the template machinery of dynamically assembled projections (why dynamic moved least).

[zantvoort]

Closing after a final measurement pass over the remaining tail. The candidates (binding-session and parameter-list carriers, compilation-key sizing, template combination, a plain-value fast path in expression binding) were implemented and measured: 0 to 1% at the operation level, below the value of the code churn. The structural work shipped in #296 and #297 stands at a 38-45% per-operation allocation reduction on the short workloads and 17% on dynamically assembled projections. Remaining allocation is dominated by per-operation value carriers that exist by design.