Optimize allocation in get_pooled_transaction_elements by pre‑allocating capacity #1764
Description
Describe the feature
Problem
In get_pooled_transaction_elements, we first build txs via filter_map + collect::<Vec<_>>() and then extend(...) with results from protocol_pool. Because filter_map produces an iterator with an imprecise size_hint, collect can’t pre‑allocate effectively, and the subsequent extend may trigger another reallocation and memcpy.
Why it matters
- filter_map makes the iterator’s size unknown, so collect often grows Vec incrementally.
- extend may then reallocate and copy existing elements.
- With large tx_hashes, this adds avoidable allocations and memcpy overhead.
Where
In get_pooled_transaction_elements, the AA‑2D branch builds txs via collect, then appends the protocol pool results.
Suggested direction
- Pre‑allocate using a known upper bound: Vec::with_capacity(tx_hashes.len()).
- Push AA‑2D results directly into txs, then reserve(protocol_txs.len()) (or extend after reserving) before appending protocol‑pool results.
Additional context
No response