Benchmarks

Benchmarks

Rambla's thesis is not "faster setters." It is "far fewer UI notifications under sustained load." Full methodology and reproduction: BENCHMARKS.md.

All numbers are indicative (ShortRun, single dev machine, .NET 10). Reproduce before quoting.

The headline is architectural, not a multiplier

100,000 mutations → ~101 effective notifications — a ~99.9% reduction.

That reduction is a directly observable property of the coalescing model, independent of any simulated cost. The time multiplier depends on how expensive each notification is — so we report the reduction as the headline.

Notifications under load

100,000 writes to one property; the Subscriber models the downstream cost each notification triggers (binding + layout + render).

Subscriber	Naive mean	Naive alloc	Rambla mean	Rambla alloc	Ratio (R/N)
No-op	~599 µs	2,344 KB	~1,010 µs	12 KB	1.68 — naive wins
CPU = 64	~7,627 µs	2,344 KB	~1,013 µs	12 KB	0.13
UI-like ×5	~11,041 µs	21,871 KB	~1,026 µs	32 KB	0.09

• No-op subscriber → naive wins on raw CPU. No downstream work to avoid; Rambla only adds bookkeeping. The honest caveat, stated up front.
• Realistic cost → Rambla wins big (~11× faster, ~680× less allocation), because it delivers ~101 notifications instead of 100,000.

Break-even

Crossover at ≈ 30 ns of downstream work per notification. A real WPF binding update costs far more, so live UIs sit well past it.

Where Rambla loses (published on purpose)

Coalescing depends on update-stream entropy. 100k writes across N distinct properties per window:

Distinct props	Coalescing	Verdict
1	99.9 %	ideal
100	90.0 %	strong
1,000+	0.0 %	Rambla loses

When distinct properties per window approach the write count, coalescing → 0% and Rambla is pure overhead. That is the boundary of where Rambla belongs — see Philosophy.

The live macrobenchmark

The market dashboard sample adds a producer → visible latency probe (p50/p95/p99) so you can sweep the refresh rate and find the knee where MaxRefreshRate should sit (usually ~60 Hz).