Identifier-only binding performance

What these benchmarks measure

Each binding uses a unique field name (f0, f1, …) and a unique model object. This ensures watchers are not shared across bindings — each binding creates its own watcher. This is the realistic worst case for identifier-only bindings: no sharing, maximum isolation.

Three metrics are measured:

• Bind time — create the binding, register the watcher, do the initial read. Includes AOT plan lookup (compiled mode) or AST clone (tree mode).
• Bulk update time — change every model field; every binding re-evaluates. Worst case: N updates, N re-evaluations.
• Single update time — change one model field; one binding re-evaluates. Best case: O(1) regardless of total binding count.

Bind time

Bind time scales linearly with binding count. For identifier-only expressions, compiled and tree mode are within a few percent of each other — the expression is so simple that the compilation overhead in compiled mode roughly equals the AST clone overhead in tree mode. There is no clear winner here; both modes are fast.

Bulk update time

When every model field changes at once, every binding re-evaluates. For identifier-only expressions with unique fields this is the O(N) worst case. Even so, 10,000 bindings complete their bulk re-evaluation in under 50 ms in both modes.

At this expression complexity, compiled mode offers a modest improvement — roughly 10–15% faster at 10,000 bindings. The advantage grows significantly for more complex expressions.

Single update time

When one field changes, exactly one binding re-evaluates. Because rs-x uses per-field watchers, updating one field does not touch any other binding regardless of how many bindings exist. This is the key property that makes rs-x scale: update cost is O(1) with respect to total binding count.

The single update time stays below 0.1 ms across all measured binding counts — and is essentially the same at 1,000 as at 10,000 bindings. This is the most important number for applications where only a few fields change at a time (which is almost all real applications).

Conclusion: single update time does not grow with binding count. This is the defining property of rs-x's reactive architecture. You only pay the O(N) cost when N fields all change simultaneously — the typical case of one or a few fields changing at a time stays O(1) no matter how large your binding graph is.

Scale reference: bind and update at larger counts

The following table extends to larger binding counts using the tree engine mode. It shows raw bind time and update performance as a reference for capacity planning.

Bind + init includes the time to complete the initial reactive evaluation cycle after binding — i.e. until every expression has its first value. This is typically higher than raw bind time because it waits for the reactive scheduler to settle.