Opt target — `pipeline`: 1.12x Node, **1.74x instructions at ~1.05x cycles**

[proggeramlug]

Opt target — pipeline: 1.12x Node, 1.74x instructions at ~1.05x cycles

#8592 closed, and pipeline improved 1.18x → 1.12x. But the diagnosis that made it
interesting is unchanged: it still retires ~74% more instructions than Node while spending
almost no extra cycles. The gap is still waiting, not computing.

Measurement — quiet M1 mini, 5 shuffled interleaved repeats, verdict CLEAN, perry adbebbe9d

	node	perry	ratio
wall	0.098 s	0.109 s	1.12x
instructions	—	—	1.74x
peak RSS	—	—	0.25x

The worked example is asyncpipe

That row had exactly this signature — 1.07x wall against 1.71x instructions — and #8570 flipped
it to 0.83x by suppressing redundant same-thread promise-drain wakeups and removing
per-element closure/guard/chained-promise allocations from the intrinsic Promise.all path. Its
instruction ratio fell to 1.32x as a by-product.

pipeline is the last row still showing that signature. The same class of fix is the first
thing to try.

What NOT to do

Do not reach for a sampler. Aggregating sample over 14 runs of asyncpipe (~88 ms) yielded
one usable self-time sample, because the process is parked rather than running. A profiler
shows a flat, uninformative profile and you conclude wrongly that there is nothing to fix.

Instrument instead: event-loop wakeups and how many are redundant with a drain already in
flight; microtask drains and jobs consumed per drain; timer registrations and due-time-to-run
latency; per-element allocations on intrinsic paths.
PROFILE_NOTIFY_DRAIN_SUPPRESSED_COUNT from #8570 is the working example of making this class
countable.

Acceptance

Wall time is the primary signal here, unusually — the instruction count is known not to be
the constraint. Many interleaved repeats with reported spread; treat a wall delta as real only
when ranges are disjoint. 20-row corpus byte-exact, whole-corpus timing, no RSS trade.