Latest Results
Cover the remaining var operation families and size every body alike
Five families had no benchmark at all. Each is a plausible target for a
later change, and none of them would have shown one:
- test_iteration_operations: map, filter, reduce and flat_map, what
rx.foreach builds. Each traces its Python callable into an
ArgsFunctionOperation first, making them the costliest per operation.
- test_datetime_operations: the date and datetime comparisons, which put
both operands into a compareDatetime call.
- test_cast_operations: to_string(), to() and bool(), reached by every
rx.text(State.count) and every truthiness check. bool() interpolates
its operand; the other two build through a function call and a
ToOperation, so both shapes are covered.
- test_array_range_operation: the sibling of test_array_index_operation,
the other @var_operation rendering its operands with !s.
- test_match_operation: an rx.match switch, built from its cases rather
than by interpolating operands.
Size every body alike. They ranged from 65 µs to 3.8 ms, and the small
end is where a benchmark stops measuring its own work: fixed call
overhead dominates, and an unrelated change reads as a regression.
Each benchmark now repeats its operation set enough times to build about
two milliseconds' worth, held in a named constant per family, so the
spread is 1.7-2.9 ms rather than 58x. The chained benchmark builds the
same total at every depth instead of one operation per level, so its
three variants finally compare to each other.
Measured over six full runs, per-benchmark spread is 2-7%, with the
noisiest at 14%; the wall-clock harness is the floor there, and CI
measures instruction counts rather than time.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011iWSDifWdaPBHA3aT53Q7Zclaude/funny-gates-2fu0d0 Make each var operation benchmark measure one operation family
test_cond_operations built one ternary and three other operations per
iteration — rx.cond(count > i, label.upper(), label.lower()) is a
comparison and two string operations wrapped around the cond, so most of
what it measured was already covered by test_comparison_operations and
test_string_operations. The same held, more mildly, elsewhere:
test_array_operations indexed and upper-cased, test_object_operations
did arithmetic, and the arithmetic and comparison bodies nested their
own results, folding in the cost of a freshly built operand that
test_chained_operations already isolates.
Flatten every family to the operations it names, over operands built
outside the measured body, and let test_chained_operations own nesting
and test_evaluate_var_heavy_page own the realistic mix. Consequently the
per-family numbers are smaller and mean something: flat arithmetic and
comparisons move 1.2-1.4x where the nested versions read 3x.
Three findings from splitting them up:
- String + is left out of test_string_operations. It builds a
ConcatVarOperation, which assembles its expression with str() and
never interpolates an operand at all.
- Array indexing gets its own benchmark. array_item_operation renders
its operands with !s, which likewise calls str() rather than
__format__, so it is built differently from the rest of the family.
- The component-var operand flavor is dropped. It measured the same as
the state-var one, because a state var's VarData already carries
imports, hooks and app wraps, and VarData caches its own hash.
Add test_boolean_operations: & and | interpolate both operands into a
pyAnd/pyOr call and carry their own imports, and nothing covered them
except as a by-product of the comparison body.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011iWSDifWdaPBHA3aT53Q7Zclaude/funny-gates-2fu0d0 Latest Branches
0%
claude/funny-gates-2fu0d0 0%
claude/automemoized-forwardref-protocol-w2fe3p +14%
benedikt-bartscher:explicit-event-id-minification © 2026 CodSpeed Technology