From 84b4dd56bed7a15ea6a04e67ea9062d81edbd357 Mon Sep 17 00:00:00 2001 From: John Kerl Date: Fri, 19 Jun 2026 17:04:19 -0400 Subject: [PATCH] Pool DSL stack-frame sets across UDF/subroutine calls (~31% perf on function-heavy `mlr put`) (#2088) * 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 * Pool DSL stack-frame *sets* across UDF/subr calls (~31% on function-heavy put) Companion to the per-block frame pooling: that left PushStackFrameSet / PopStackFrameSet (entered once per user-defined function or subroutine call) allocating. Each call did newStackFrameSet() -- a StackFrameSet plus its initial StackFrame (a slice and a map) -- AND, worse, prepended it with append([]*StackFrameSet{head}, sets...), allocating a fresh backing slice and copying the whole save-stack every call. Two changes: - Treat the frameset save-stack as a tail stack (append to push, truncate to pop) instead of prepending at index 0. get/set only ever touch the cached head, so list order is irrelevant; this removes the per-call slice realloc + O(depth) copy. - Pool popped framesets (LIFO) and reset-and-reuse them on the next push, mirroring the per-frameset frame free list. A reset trims back to one cleared base frame (extras go to the frame pool). After warmup, repeated calls allocate no framesets or frames. Measured (big.csv, 1M rows, best of 5): put, 2 nested func calls/record: 2.73 -> 1.87 (~31%) GC cycles 25 -> 16; newStackFrameSet/newStackFrame fall out of the allocation profile entirely. (chain-1 etc. have no UDFs and are unaffected.) Verified: go test ./pkg/... and full regression suite pass; recursion (fact/fib), local-scope isolation, and subroutine+oosvar all correct. Co-Authored-By: Claude Opus 4.8 --------- Co-authored-by: Claude Opus 4.8 --- pkg/runtime/stack.go | 46 ++++++++++++++++++++++++++++++++++++-------- 1 file changed, 38 insertions(+), 8 deletions(-) diff --git a/pkg/runtime/stack.go b/pkg/runtime/stack.go index 5a707e8c3..c2e8255a6 100644 --- a/pkg/runtime/stack.go +++ b/pkg/runtime/stack.go @@ -62,19 +62,26 @@ func (sv *StackVariable) GetName() string { // STACK METHODS type Stack struct { - // list of *StackFrameSet + // Save/restore stack of framesets, one pushed per user-defined + // function/subroutine call. The CURRENT frameset is the tail element + // (stackFrameSets[len-1]); pushing appends and popping truncates, so neither + // allocates a new slice once capacity is established. (Order among the saved + // sets is irrelevant: all get/set go through the cached head.) stackFrameSets []*StackFrameSet - // Invariant: equal to the head of the stackFrameSets list. This is cached + // Invariant: equal to the tail of the stackFrameSets list. This is cached // since all sets/gets in between frameset-push and frameset-pop will all // and only be operating on the head. head *StackFrameSet + + // pool retains popped framesets for reuse, so repeated function calls do not + // each allocate a fresh StackFrameSet (and its initial StackFrame). + pool []*StackFrameSet } func NewStack() *Stack { - stackFrameSets := make([]*StackFrameSet, 1) head := newStackFrameSet() - stackFrameSets[0] = head + stackFrameSets := []*StackFrameSet{head} return &Stack{ stackFrameSets: stackFrameSets, head: head, @@ -83,14 +90,26 @@ func NewStack() *Stack { // For when a user-defined function/subroutine is being entered func (stack *Stack) PushStackFrameSet() { - stack.head = newStackFrameSet() - stack.stackFrameSets = append([]*StackFrameSet{stack.head}, stack.stackFrameSets...) + var frameset *StackFrameSet + n := len(stack.pool) + if n > 0 { + frameset = stack.pool[n-1] + stack.pool = stack.pool[:n-1] + frameset.reset() + } else { + frameset = newStackFrameSet() + } + stack.stackFrameSets = append(stack.stackFrameSets, frameset) + stack.head = frameset } // For when a user-defined function/subroutine is being exited func (stack *Stack) PopStackFrameSet() { - stack.stackFrameSets = stack.stackFrameSets[1:] - stack.head = stack.stackFrameSets[0] + n := len(stack.stackFrameSets) + popped := stack.stackFrameSets[n-1] + stack.stackFrameSets = stack.stackFrameSets[0 : n-1] + stack.pool = append(stack.pool, popped) + stack.head = stack.stackFrameSets[len(stack.stackFrameSets)-1] } // All of these are simply delegations to the head frameset @@ -195,6 +214,17 @@ func newStackFrameSet() *StackFrameSet { } } +// reset returns a pooled frameset to its freshly-constructed state: exactly one +// (cleared) base frame. Any extra frames are kept in the per-frameset frame +// pool for reuse. At a balanced PopStackFrameSet the set is already at depth 1, +// so this is normally just a clear of the base frame. +func (frameset *StackFrameSet) reset() { + for len(frameset.stackFrames) > 1 { + frameset.popStackFrame() + } + frameset.stackFrames[0].clear() +} + func (frameset *StackFrameSet) pushStackFrame() { n := len(frameset.pool) if n > 0 {