perf: optimize was_applied fast path for known LWT statements (~1.5us, 1.1x speedup)

[mykaul]

Summary

• Add fast path in ResultSet.was_applied for statements where query.is_lwt() is True (BoundStatement/PreparedStatement)
• Skips the expensive batch_regex.match() call and isinstance(query, BatchStatement) check for the common single-LWT case
• Non-LWT and batch statements fall through to the existing slow path unchanged

Benchmark

Measured with min() of timeit.repeat(repeat=7, number=200_000) on a quiet machine (load <1).

Path	Per-call	Speedup
Slow path (non-LWT, regex check)	7536 ns	baseline
Fast path (known LWT, skip regex)	6924 ns	1.1x

Savings: 612 ns/call

Tests

• 4 new focused tests: test_was_applied_lwt_fast_path, test_was_applied_non_lwt_fallback, test_was_applied_batch_statement
• Updated existing test_was_applied to use explicit non-LWT query to exercise the slow (regex) path
• Full unit test suite passes (648 passed)

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9a0fa52d-082c-40b0-b2f4-47572ac7494b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[mykaul]

Rebased onto latest master (no conflicts) and did a correctness review focused on whether the new fast path could ever disagree with the slow path about LWT-ness, given the correctness findings elsewhere this session around is_lwt().

Consistency verdict: safe. The fast path doesn't introduce a new LWT-detection heuristic — it reuses the single canonical query.is_lwt() accessor that the rest of the driver already trusts (e.g. policies.py's Paxos-routing shuffle decision reads the same flag). That flag is sourced entirely from the server's SCYLLA_LWT_ADD_METADATA_MARK PREPARE-response bit (cassandra/lwt_info.py / protocol.py), not a client-side string/regex guess, so it isn't subject to the string-detection concerns raised on #784.

Tracing where response_future.query can actually come from (Session._create_response_future always turns a bare string into SimpleStatement and auto-binds a PreparedStatement into a BoundStatement), the only three concrete types reaching was_applied are SimpleStatement, BoundStatement, and BatchStatement:

• SimpleStatement.is_lwt() is inherited from the Statement base and is hard-coded False (never set from a PREPARE response), so it can never trigger the fast path — it always falls through to the same regex check as before.
• BatchStatement is explicitly excluded from the fast path via not isinstance(query, BatchStatement), regardless of its (possibly aggregated-True) is_lwt(), so batches always take the slow path unchanged.
• That leaves BoundStatement as the only type that can hit the fast path, and a BoundStatement is never a "batch" under the slow path's own is_batch_statement test (isinstance(..., BatchStatement) or (isinstance(..., SimpleStatement) and batch_regex.match(...)) — both are False for it). So whenever the fast path fires, the slow path would have computed is_batch_statement=False too, and would run the exact same len(current_rows) != 1 check. The two paths are provably equivalent for every reachable case — not just "usually agree."

Also checked HostTargetingStatement's dynamic-subclassing trick (used for graph host targeting) — since it copies __dict__ and subclasses the inner statement's class, isinstance and is_lwt() both resolve correctly through it, so no gap there either.

No correctness fix was needed. I rebased the two commits onto current master (amended in place, no new commits) and ran:

• tests/unit/test_query.py, tests/unit/test_response_future.py, tests/unit/test_resultset.py: 78 passed
• Full tests/unit/: 723 passed, 88 skipped (pre-existing skips), 0 failures

CI on the PR is green (13/13 checks) and there were no unresolved review threads to address. Force-pushed the rebased branch to mykaul/perf/optimize-was-applied; PR remains a draft.

[Copilot]

Pull request overview

Note

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Optimizes ResultSet.was_applied by adding a fast path for queries that already know they are LWT statements, avoiding expensive batch detection in the common single-LWT case.

Changes:

• Add query.is_lwt()-based fast path in ResultSet.was_applied to skip batch regex detection for non-batch known-LWT statements
• Update and add unit tests to cover fast-path, slow-path fallback, and batch behavior
• Add a micro-benchmark script to measure the fast-path vs slow-path overhead

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
cassandra/cluster.py	Adds LWT fast path in ResultSet.was_applied to skip batch detection when LWT is known
tests/unit/test_resultset.py	Adds tests for fast/slow paths and adjusts existing test to avoid accidental fast-path routing
benchmarks/bench_was_applied.py	Introduces micro-benchmark comparing fast-path checks vs regex-based slow path

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

cassandra/cluster.py:5923

• This does not remove the work claimed by the fast path. In the previous code, batch_regex.match() was already guarded by isinstance(query, SimpleStatement), so a BoundStatement never ran the regex; this branch still performs the BatchStatement check and now adds getattr, callable, and an is_lwt() call. The target BoundStatement path is therefore likely slower rather than faster. Please restore the existing path unless an apples-to-apples benchmark demonstrates an actual reduction, or redesign the branch to eliminate work that BoundStatements previously performed.

        is_lwt = getattr(query, 'is_lwt', None)
        if not isinstance(query, BatchStatement) and callable(is_lwt) and is_lwt():

benchmarks/bench_was_applied.py:74

• This benchmark cannot attribute its reported “speedup” to this PR: it compares a BoundStatement with a SimpleStatement, but the pre-PR implementation already skipped the regex for BoundStatements. It would report a difference even on the base branch. It also uses one timeit() run rather than the min(timeit.repeat(..., repeat=7)) methodology stated in the PR. Please compare the same BoundStatement workload before and after the implementation (and use repeated runs) so the claimed regression/improvement is reproducible.

    t_fast = timeit.timeit(fast_path, number=n)
    t_slow = timeit.timeit(slow_path, number=n)