diff options
author | fanquake <fanquake@gmail.com> | 2022-01-25 10:51:29 +0800 |
---|---|---|
committer | fanquake <fanquake@gmail.com> | 2022-01-25 11:20:18 +0800 |
commit | 0147278e37d0bc244bcc6a10ad860e16fef055fa (patch) | |
tree | cb6dc1e82c40573aebb33ebcca459d6f62a8a9e8 /build_msvc | |
parent | 417e7503f80b8b9cfccd43131f313de8defc0ad5 (diff) | |
parent | c5b36b1c1b11f04e5da7fb44183f61d09a14e40d (diff) |
Merge bitcoin/bitcoin#21464: Mempool Update Cut-Through Optimization
c5b36b1c1b11f04e5da7fb44183f61d09a14e40d Mempool Update Cut-Through Optimization (Jeremy Rubin)
c49daf9885e86ba08acdc8332d2a34bc5951a487 [TESTS] Increase limitancestorcount in tournament RPC test to showcase improved algorithm (Jeremy Rubin)
Pull request description:
Often when we're updating mempool entries we update entries that we ultimately end up removing the updated entries shortly thereafter. This patch makes it so that we filter for such entries a bit earlier in processing, which yields a mild improvement for these cases, and is negligible overhead otherwise.
There's potential for a better -- but more sophisticated -- algorithm that can be used taking advantage of epochs, but I figured it is better to do something that is simple and works first and upgrade it later as the other epoch mempool work proceeds as it makes the patches for the epoch algorithm simpler to understand, so you can consider this as preparatory work. It could either go in now if it is not controversial, or we could wait until the other patch is ready to go.
ACKs for top commit:
instagibbs:
reACK c5b36b1
sipa:
utACK c5b36b1c1b11f04e5da7fb44183f61d09a14e40d
mzumsande:
Code Review ACK c5b36b1c1b11f04e5da7fb44183f61d09a14e40d
Tree-SHA512: 78b16864f77a637d8a68a65e23c019a9757d8b2243486728ef601d212ae482f6084cf8e69d810958c356f1803178046e4697207ba40d6d10529ca57de647fae6
Diffstat (limited to 'build_msvc')
0 files changed, 0 insertions, 0 deletions