Performance issue with get_chain_position
and associated methods for unconfirmed transactions
#1665
Labels
Milestone
Describe the bug
get_chain_position
for unconfirmed transactions is very inefficient if we have "nested conflicts". Since unconfirmed transactions that spend from evicted transactions are also evicted, we need to iterate over and check all unconfirmed descendants.This problem is exacerbated in
list_canonical_txs
,filter_chain_txouts
, etc. as these methods callget_chain_position
for each transaction.Worst case is
O(n^2)
for building the canonical tx history.Proposed Solution
Let's pass an
evicted_txs: &mut HashSet<Txid>
input toget_chain_position
which takes record of any tx that is deemed to be evicted from the canonical history. Note that descendants of evicted transactions are also evicted and should be included inevicted_txs
. The logic to fillevicted_txs
can stop when we insert an already-existingtxid
(since descendants of thattxid
will already be included inevicted_txs
).list_canonical_txs
,filter_chain_txouts
, etc. methods will construct anevicted_txs
hashset which is passed to each internal call totry_get_chain_position
.The text was updated successfully, but these errors were encountered: