When freeing memory raises a downstream cost, split the A/B into the fix itself and the policy that reacts to it

A memory-release fix in a streaming writer cut peak RSS by 33-49%, but the same A/B also showed +1.5% file size and up to +4% CPU. Without care it reads as a trade-off. Splitting the runs separated two effects: (1) with the segment-cut trigger disabled, old and new produced byte-identical files at unchanged CPU, so the fix itself was free; (2) with the trigger on, the trigger fired about twice as often, because it counted freed buffers regrowing as new growth, and the extra segments caused the size and CPU cost. So the right action was to fix the policy (exclude reusable buffers from the growth measure), not to reject the memory fix. General method: when a change interacts with an adaptive policy (cut/flush/GC thresholds), run the A/B once with the policy pinned or off to measure the change alone, then with it on, and report both rows with the event count (cuts, flushes) next to size, CPU and memory.