update_checkpoints() makes a few DNS requests and can take up to 20-30 seconds to complete (3-6 seconds on average). It is currently called from core::handle_incoming_block() which holds m_incoming_tx_lock, so it blocks all incoming transactions and blocks processing while update_checkpoints() is running. This PR moves it to until after a new block has been processed and relayed, to avoid full monerod locking.
Before the fix, it processed all transactions in the mempool which could be very slow when mempool grows to several MBs in size. I observed `get_block_template_backlog` taking up to 15 seconds of CPU time under high mempool load.
After the fix, only transactions that can potentially be mined in the next block will be processed (a bit more than the current block median weight).
All tests were conducted on the same PC (Ryzen 5 5600X running at fixed 4.65 GHz).
Before:
test_cn_fast_hash<32> (100000 calls) - OK: 1 us/call
test_cn_fast_hash<16384> (1000 calls) - OK: 164 us/call
After:
test_cn_fast_hash<32> (100000 calls) - OK: 0 us/call
test_cn_fast_hash<16384> (1000 calls) - OK: 31 us/call
More than 5 times speedup for cn_fast_hash.
Also noticed consistent 1-2% improvement in test_construct_tx results.
There are duplicate headers for 'amount' when performing export_transfers
all. Column five represents the total amount of the transaction while
column eleven represents the amount transferred per destination (e.g.
multi-destination transactions). The columns have been renamed to
'transaction amount' and 'destination amount` respectively.
when kicking a peer for inactivity, clear the set of requested blocks,
or next time we requests blocks from it, we'll probably reject the
incoming blocks due to missing the previous requested blocks
- combined with patching integer truncation (#7798), this gets the algorithm marginally closer to mirroring empirically observed output ages
- 50 was originally chosen assuming integer truncation would remain in the client for that client release version. But patching integer truncation causes the client to select more outputs in the 10-100 block range, and therefore the benefit of choosing a larger recent spend window of 50 has less merit
- 15 seems well-suited to cover the somewhat sizable observable gap in the early window of blocks
SerHack
moneromooo-monero
Lee Clagett
SChernykh
j-berman
selsta
Howard Chu
tobtoht
hinto.janaiyo
Dusan Klinec
Luke Parker
koe
Mathias Herberts
Jeffrey
reemuru
woodser
xiphon
rbrunner7
anon
j-berman
mj-xmr
Nathan Dorfman