From dcb9897b0a1ddb6d1a7f20b42fbaeb4b5407fe6f Mon Sep 17 00:00:00 2001 From: John Kerl Date: Fri, 19 Jun 2026 17:05:51 -0400 Subject: [PATCH] Bind scalar locals/params by reference, not by copy (~4-9% on DSL) (#2090) * 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 * Drop redundant deep-copy of UDF return values (~3-16% on UDF put) A user-defined function's return value was deep-copied twice on the way out: once in ReturnNode.Execute (returnValue.Copy() when building the block-exit payload) and again in UDFCallsite.EvaluateWithArguments (blockReturnValue.Copy() at the end). The ReturnNode copy is the necessary one: it detaches the value from the callee's frame so it survives the frame being popped (and, since perf-try-7, pooled/reused). By the time EvaluateWithArguments returns, blockReturnValue is therefore already an independent deep copy, so the second copy is pure waste -- and callers that retain the result copy again anyway (field/oosvar/local assignment all PutCopy/Copy). The other return paths (implicit-absent, error) don't use blockReturnValue, so this only affects the BLOCK_EXIT_RETURN_VALUE path. Return blockReturnValue directly. Measured (big.csv, 1M rows, best of 5): put, 2 nested scalar-returning calls/record: 1.89 -> 1.83 (~3%) put, map-returning func per record: 2.34 -> 1.97 (~16%) Win scales with return-value size (the avoided copy is deep). All UDF/HOF callsites (apply/reduce/sort/select/fold/...) go through this path. Verified: go test ./pkg/... and full regression suite pass; recursion, HOFs, and returned-map isolation (mutating a returned map does not affect a subsequent call) all correct. Co-Authored-By: Claude Opus 4.8 * Bind scalar locals/params by reference, not by copy (~4-9% on DSL) NewTypeGatedMlrvalVariable and TypeGatedMlrvalVariable.Assign deep-copied every value bound to a local variable or function parameter -- ~6.9M allocations on a UDF-heavy put. For scalars that copy is unnecessary: Aliasing audit. Assignment everywhere REPLACES pointers rather than mutating Mlrvals in place: Mlrmap.PutCopy reassigns pe.Value, Assign reassigns tvar.value. The only in-place mutation a scalar undergoes is idempotent type-inference caching (printrep -> typed). So a local/param bound by reference to a scalar source can never observe its source change, and reassigning the local replaces its own pointer without touching the source -- capture-by-value semantics are preserved. Maps and arrays, by contrast, ARE mutated in place by indexed assignment (m[k]=v), so an aliased collection would corrupt its source; those must still be deep-copied. So copyForBind copies only arrays/maps and binds scalars by reference. (Return values are independently safe: ReturnNode.Execute still deep-copies them.) Measured (big.csv, 1M rows, best of 5): UDF-heavy put (scalar args/locals): 1.84 -> 1.68 (~9%) x = $a+$b; $s = x*2 (no UDF): 0.50 -> 0.48 (~4%) Verified: go test ./pkg/... and full regression suite pass, plus targeted alias-then-mutate tests: scalar locals capture-by-value (source change after bind not observed; reassigning one of two aliases leaves the other intact; mutating a scalar param leaves the caller field intact), and collections stay independent (local/param/oosvar-element map copies isolate in-place mutation). Co-Authored-By: Claude Opus 4.8 --------- Co-authored-by: Claude Opus 4.8 --- pkg/types/mlrval_typing.go | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/pkg/types/mlrval_typing.go b/pkg/types/mlrval_typing.go index a8df0abd9..8bc54d4bc 100644 --- a/pkg/types/mlrval_typing.go +++ b/pkg/types/mlrval_typing.go @@ -46,6 +46,22 @@ type TypeGatedMlrvalVariable struct { value *mlrval.Mlrval } +// copyForBind returns the value to store when binding a local variable or +// function parameter. Scalars are stored by reference (no copy, no allocation): +// assignment everywhere replaces pointers rather than mutating Mlrvals in place +// (Mlrmap.PutCopy reassigns pe.Value; Assign reassigns tvar.value), and the +// only in-place mutation a scalar undergoes is idempotent type-inference +// caching -- so an aliased scalar can never be observed to change underneath +// its source. Maps and arrays, however, ARE mutated in place by indexed +// assignment (m[k]=v), so they must be deep-copied to keep the binding +// independent of its source. +func copyForBind(value *mlrval.Mlrval) *mlrval.Mlrval { + if value.IsArrayOrMap() { + return value.Copy() + } + return value +} + func NewTypeGatedMlrvalVariable( name string, // e.g. "x" typeName string, // e.g. "num" @@ -63,7 +79,7 @@ func NewTypeGatedMlrvalVariable( return &TypeGatedMlrvalVariable{ typeGatedMlrvalName, - value.Copy(), + copyForBind(value), }, nil } @@ -77,8 +93,7 @@ func (tvar *TypeGatedMlrvalVariable) Assign(value *mlrval.Mlrval) error { return err } - // TODO: revisit copy-reduction - tvar.value = value.Copy() + tvar.value = copyForBind(value) return nil }