Upload in batches of 4
Requirement
Ten files are queued for upload and the API accepts at most four per request. Group the queue into batches of 4 (the last one is short) and print each batch's size and ids. The data is in the code; both versions must print the lines shown under Expected output.
Expected output
batch of 4: img-01 img-02 img-03 img-04 batch of 4: img-05 img-06 img-07 img-08 batch of 2: img-09 img-10
Side by side
RxDart
FxDart
Why they differ
Non-overlapping batching is core vocabulary in both models, and both
say it in one word: bufferCount(4) collects four events
before emitting a List, chunk(4) pulls four
values into a List per demand. Both flush the short
trailing batch when the source runs out. The map that
formats each batch is then character-for-character identical.
Where the models would start to diverge is just outside this
example's frame. A stream buffers because values arrive on their own
schedule — bufferCount also has time-based siblings
(bufferTime) that a pull pipeline deliberately doesn't
offer, because "what arrived in the last second" has no meaning when
the consumer controls arrival. A pull chain chunks because the
consumer wants four-at-a-time demand — which is also why
chunk composes directly with downstream concurrency
(send each batch while assembling the next). For a fixed queue of
ten, neither advantage is exercised: a tie.
Benchmark
N = 100
Time Tie
Peak memory Tie
N = 1,000,000
Time FxDart wins
Peak memory Tie
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.