[lupin012]

Problem

When a receipt is not in the receipt LRU, eth_getLogs reads it with PersistedReceipt, which first computes the transaction hash with TxnHashByIdxInBlock (the stored receipt has no hash; it only fills transactionHash). For a block in files this:

1. decompresses and decodes the whole block body only to read BaseTxnID, once for every transaction of the block;
2. creates a new Getter and a new buffer for the transaction RLP, then hashes it.

With the default receipt cache and wide filters (many addresses, many logs per request) TxnHashByIdxInBlock was 39-41% of the process CPU and 34% of the bytes allocated by the node; the body part alone (BodyForTxnFromSnapshot) was 9.4% of the CPU.

Change

• TxnHashByIdxInBlock takes the txNum of the transaction (the only caller, PersistedReceipt, already has it).
• Block files use the canonical txNum as transaction id (DumpBodies writes body.BaseTxnID as the canonical txNum, see block_snapshots.go), so for a frozen block the transaction is read from the transactions file by txNum, without reading the body. The read uses a pooled buffer.
• The fast path is taken only when the block is in files, the index is not negative (system transactions) and txNum is inside the id range of the transactions file; otherwise the previous code runs unchanged. Blocks still in the DB are not affected.
• txnRlpByID returns nil for an empty word instead of panicking: system transactions without data are stored as empty words, and the fast path no longer has the body check in front of it.

Pure performance change, no behaviour change. TDD note: the existing frozen-blocks test now checks the hash of every block of a frozen segment and of the DB tail against the block's transaction (a mutation of txNum makes it fail), and a new case covers the empty-word panic found during review (red before the guard, green after).

Results

Mainnet node (--prune.mode=minimal), default receipt cache, rpc_perf without HTTP compression, patterns of 20000 requests over the last 3000 blocks (100-block ranges), rounds base / opt / opt / base, median of the two rounds. 1200 sampled responses are byte-identical between base and this branch.

At 1000 qps:

filter	CPU ms/req	KiB alloc/req	mallocs/req	p50	p95	p99
1 address	-15%	-29%	-17%	-9%	-16%	-17%
up to 16 addresses	-14%	-26%	-15%	-14%	-17%	-17%
up to 16 addresses + topics	~0 (noise)	-24%	-14%	0%	-9%	-11%
topics, up to 16 values per position	~0 (noise)	-15%	-7%	-1%	-4%	-7%

At 2000 qps the single-address pattern gets -21% CPU/req and -22..-24% p95/p99. CPU profile: BodyForTxnFromSnapshot 9.4% -> 0%; allocations: TxnHashByIdxInBlock 34% -> 7% of the allocated bytes.

The two rounds of each variant agree closely (e.g. 16 addresses: base 9.12 / 9.00 ms/req, opt 7.58 / 7.45 ms/req; p95 base 46.5 / 46.6 ms, opt 38.7 / 38.1 ms).

[AskAlexSharov]

Looks good. Ship.