本页尚未翻译,因此以英文显示。 参与翻译

A pipeline feeds a stream consumer

Toss-up async

Requirement

Fetch five order statuses, at most two requests in flight, results in source order — then hand them to a downstream consumer that batches them in pairs and prints each batch. The lookup delays are fixed in the code; both versions must print the lines shown under Expected output.

Expected output
batch 1: A-101 shipped | A-102 packed
batch 2: A-103 allocated | A-104 delayed
batch 3: A-105 shipped

Side by side

RxDart

FxDart

Why they differ

RxDart runs streams end to end: flatMap with maxConcurrent: 2 bounds the fetches and bufferCount(2) pairs the results. One caveat lives in the middle: concurrent flatMap emits in completion order, so this panel only prints in source order because the delays happen to complete that way — reordering under concurrency is the push model's default, and keeping source order in general means collecting and sorting.

The FxDart panel is the previous example's bridge crossed in the other direction. The fetching half is a pull pipeline — mapConcurrent(2, …) is ordered by construction, whatever the delays do — chunk(2) (FxDart's bufferCount) pairs the results, and toStream() hands the batches to any stream consumer. Here that consumer only prints, and in an RxDart app it could keep going with Rx operators on the bridged stream: the producer does not care who consumes. That division of labor is the verdict: do bounded, ordered, typed work in the pull pipeline, expose it as a Stream, and let the push world take over where push vocabulary (buffering, debouncing, UI binding) is the better fit. Tie — the bridge is the point.

Benchmark

Apple M1 Max, 32 GB RAM · Dart 3.12.2 (AOT-compiled) · 2026-08-18

Async case: the headline scale is N = 10,000, not 1,000,000. Every element costs an event-loop turn on both sides, so a million real awaits would measure Dart's event loop for minutes — not the pipeline. Delays are zero-length and the example's concurrency limit is kept; what the bars compare is the pipeline machinery.

N = 100

Time Tie

RxDart 438 µs
FxDart 415 µs

Peak memory Tie

RxDart 16.6 MB
FxDart 17.2 MB

N = 10,000

Time Tie

RxDart 36.4 ms
FxDart 36.3 ms

Peak memory FxDart wins

RxDart 50.5 MB
FxDart 30.8 MB

Bars are medians of repeated timed iterations in fresh processes per side (small N is batched for timer resolution). Sides within 5% of each other — or within 0.6 ms, a difference no person can perceive — count as a tie; close relative races are re-measured up to 5 runs. In an app, anything under a few milliseconds is invisible to the user regardless of which bar is shorter. Memory is peak process RSS. The Dart VM and the dataset are identical on both sides, so the difference between the two bars is what the pipeline itself holds onto.