Skip to content

Performance measurement: cost of the mempool txid check - #1

Closed
tvpeter wants to merge 2 commits into
masterfrom
perf/txid-check-measure
Closed

tvpeter wants to merge 2 commits into
masterfrom
perf/txid-check-measure

Conversation

@tvpeter

@tvpeter tvpeter commented Sep 11, 2026

Copy link
Copy Markdown
Owner

Description

This PR seeks to provide the performance metrics for adding compute_txid() verification check for every
fetched mempool transaction to Emitter::mempool_at
in #2283.

Tests
  • crates/bitcoind_rpc/tests/perf_check.rs — an end-to-end test using bdk_testenv (spins up a real regtest node), which broadcasts ~500 mempool txs and times get_raw_transaction (the fetch already done per tx) against the
    compute_txid() check.
  • crates/bitcoind_rpc/benches/txid_check.rs — a criterion microbench isolating the CPU cost of compute_txid() vs a bare consensus-deserialize, across three transaction sizes. Provides the absolute cost.
How to reproduce
  • Run cargo test --release -p bdk_bitcoind_rpc --test perf_check -- --nocapture for end-to-end test module
  • Run cargo bench -p bdk_bitcoind_rpc --bench txid_check for criterion benches
Results

Machine: Macbook pro M1 (16GB RAM, macOS Tahoe v26.6.2, 10 Cores CPU).

End-to-end (500 mempool txs, localhost regtest):

per tx share of fetch
get_raw_transaction (RPC round-trip + hex + deserialize — already paid) ~117 µs 100%
compute_txid() check ~1 µs ~0.85%

Isolated CPU cost (criterion, time: estimates):

tx shape compute_txid (the check) deserialize
small 1-in/2-out (223 B) ~637 ns ~263 ns
typical 2-in/2-out (372 B) ~823 ns ~362 ns
large 10-in/10-out (1.8 KB) ~2.69 µs ~1.43 µs
Interpretation
  • The check costs a stable ~0.6–2.7 µs/tx (size-dependent; ~0.8 µs typical), scaling linearly with tx size. Criterion reports "no change / within noise" across runs, so it's reproducible.
  • It's ~2× a bare deserialize, but both are sub-microsecond — and it's under 1% of the full get_raw_transaction fetch, which is dominated by the RPC round-trip.
  • Extrapolated to "thousands of txs": at ~0.8 µs/tx, a full 100k-tx mempool is ~80 ms of hashing on top of a fetch phase measured in tens of seconds (localhost) to minutes (remote). Sync is RPC/IO-bound, not hash-bound.

Conclusion: the txid check has no meaningful impact on sync performance.

Checklists

All Submissions:

- Add an end-to-end performance test for get_raw_transaction
against compute_txid

Result performed against a size of 500 unconfirmed mempool
txs indicate that compute_txid() validation introduces
a negligible performance impact, consuming just 0.946% of the
time required to get_raw_transaction.
- add criterion benchmarks for compute_txid and deserialize
across three transaction sizes. The result indicate that both
operations scale linearly with the size of the transaction,
but are both fast even for a large transaction.

The txid check costs a stable ~0.6-2.7 µs/tx (size-dependent;
~0.8 µs typical), reproducible across runs. It's roughly 2x a
bare deserialize, but both are sub-µs — and it's <1% of the full
get_raw_transaction fetch, which is dominated by the RPC round-trip.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant