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 <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>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
John Kerl 2026-06-19 17:03:49 -04:00 committed by GitHub
parent d00de0f71a
commit 99b8fbdcd5
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -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,