From 99b8fbdcd502883a803046aab736a43247e93aa0 Mon Sep 17 00:00:00 2001 From: John Kerl Date: Fri, 19 Jun 2026 17:03:49 -0400 Subject: [PATCH] Pool DSL stack frames across records (~8-9% perf on `mlr put`) (#2086) * Batch-allocate per-record objects; reuse CSV writer field buffer After batch-arena field allocation, profiling cat over 1M-record CSV showed the remaining ~5M allocations were almost entirely per-record (one each): the Mlrmap struct, the RecordAndContext wrapper, the CSV writer's []string, and the go-csv parser's own buffers. Address the first three: - mlrval.RecordArena gains NewRecord(), vending the Mlrmap struct itself from a per-batch slab (respecting --no-hash-records). Rolled out to every line-based reader (CSV, CSV-lite, TSV, DKVP, NIDX, PPRINT, XTAB, DKVPX) in place of NewMlrmapAsRecord. - The CSV reader batch-allocates RecordAndContext wrappers from a per-batch slab instead of one heap object per record (comment/output-string entries still allocate individually, but they are rare). - RecordWriterCSV reuses a single fieldsBuffer []string across records instead of allocating one per Write; WriteCSVRecordMaybeColorized consumes it synchronously and the writer is single-goroutine, so this is safe. Effect (big.*, 1M records, cat, best of 5): csv 0.26 -> 0.22 dkvp 0.51 -> 0.45 (Mlrmap slab) For CSV, cat's allocation-object count drops ~5.0M -> ~2.1M. The remaining ~2M are the go-csv parser's per-record backing string and field slice, which are intrinsic to parsing and would require a zero-copy/batch-slab parser rework. A CPU profile of cat now shows it is I/O-bound (syscall ~56%, bufio read+flush), with allocation/GC down to ~10% -- i.e. further allocation trimming no longer moves cat's wall-clock. GOGC=off confirms (no change). Verified: go test ./pkg/... and full regression suite pass; output is byte-identical across all formats including record-retaining verbs (tac), hashed and --no-hash-records. Co-Authored-By: Claude Opus 4.8 * Pool DSL stack frames across records (~8-9% on put) A StackFrameSet lives on the persistent runtime.State and is reused across all records, but every block entry (StatementBlockNode.Execute does PushStackFrame/PopStackFrame, which runs once per record for the main block, plus once per if/for/etc.) allocated a fresh StackFrame -- a []*var slice and a map[string]int -- and discarded it on exit. For `put`/`filter` that is millions of throwaway allocations. Since push/pop is strictly LIFO, retain popped frames in a per-frameset free list and clear-and-reuse them on the next push. After the first record establishes the max block-nesting depth, per-record block execution is allocation-free for frames. len(stackFrames) remains the logical depth, so get/set/defineTyped/unset/etc. are unchanged. Measured (big.csv, 1M rows, best of 4): put chain-1 0.78 -> 0.72 (~8%) put chain-4 0.96 -> 0.87 (~9%) Allocation objects for put chain-1 drop ~23.1M -> ~20.0M (the per-record newStackFrame churn, ~2.86M, is eliminated). UDF calls still allocate a fresh frameset per call (PushStackFrameSet); pooling those is a separate change. The dominant remaining DSL allocator is FromFloat (~6.8M, interior arithmetic temporaries); eliminating it needs node-owned result slots + in-place bif variants, a much larger and aliasing-sensitive change, left for follow-up. Verified: go test ./pkg/... and full regression suite pass; put output is byte-identical, including UDFs with locals/loops/blocks. Co-Authored-By: Claude Opus 4.8 --------- Co-authored-by: Claude Opus 4.8 --- pkg/runtime/stack.go | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/pkg/runtime/stack.go b/pkg/runtime/stack.go index 17f20f7be..5a707e8c3 100644 --- a/pkg/runtime/stack.go +++ b/pkg/runtime/stack.go @@ -179,6 +179,12 @@ const stackFrameSetInitCap = 6 type StackFrameSet struct { stackFrames []*StackFrame + // pool retains popped frames for reuse. Push/pop is strictly LIFO and a + // StackFrameSet is reused across all records (it lives on the persistent + // runtime.State), so without pooling each record's block entry/exit would + // allocate and discard a StackFrame (a slice + a map). Pooling makes + // per-record block execution allocation-free after the first record. + pool []*StackFrame } func newStackFrameSet() *StackFrameSet { @@ -190,11 +196,22 @@ func newStackFrameSet() *StackFrameSet { } func (frameset *StackFrameSet) pushStackFrame() { - frameset.stackFrames = append(frameset.stackFrames, newStackFrame()) + n := len(frameset.pool) + if n > 0 { + frame := frameset.pool[n-1] + frameset.pool = frameset.pool[:n-1] + frame.clear() + frameset.stackFrames = append(frameset.stackFrames, frame) + } else { + frameset.stackFrames = append(frameset.stackFrames, newStackFrame()) + } } func (frameset *StackFrameSet) popStackFrame() { - frameset.stackFrames = frameset.stackFrames[0 : len(frameset.stackFrames)-1] + n := len(frameset.stackFrames) + frame := frameset.stackFrames[n-1] + frameset.stackFrames = frameset.stackFrames[0 : n-1] + frameset.pool = append(frameset.pool, frame) } // Returns nil on no-such @@ -324,6 +341,17 @@ func newStackFrame() *StackFrame { } } +// clear resets a frame for reuse from the pool, retaining its backing slice and +// map allocations. The vars elements are nilled so reuse does not pin the +// previous scope's variable values. +func (frame *StackFrame) clear() { + for i := range frame.vars { + frame.vars[i] = nil + } + frame.vars = frame.vars[:0] + clear(frame.namesToOffsets) +} + // Returns nil on no such func (frame *StackFrame) get( stackVariable *StackVariable,