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 <noreply@anthropic.com>

* 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 <noreply@anthropic.com>

* 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 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

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 {