The last three errors
Requirement
From this morning's service log, keep only the ERROR
lines and print the last three of them, oldest
first. The data is in the code; both versions must print the lines
shown under Expected output.
Expected output
ERROR timeout contacting registry ERROR registry unreachable ERROR checksum mismatch on chunk 7
Side by side
RxDart
FxDart
Why they differ
"The last three" has a structural cost no operator can dodge: you
cannot know an element is among the last three until you have seen
the end. Both sides therefore buffer — a three-slot
window that each new error pushes into and the oldest falls out of —
and both flush it only when the source ends. RxDart's
takeLast emits nothing until the done event
arrives; FxDart's takeRight keeps the same window while
it drains the iterable to exhaustion. Same algorithm,
keyed to each model's word for "no more elements".
Upstream of that, where and filter are
interchangeable. The one model note worth making: on an unbounded
stream takeLast never emits at all — "last three" is
only meaningful for sources that end, which is native territory for
a finite iterable and a special case for a stream. On this bounded
log both express the job directly, so the verdict is 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.