Mempool: Improve mempool’s concurrency #7145

pull jtimon wants to merge 4 commits into bitcoin:master from jtimon:mempool-estimator changing 11 files +108 −122
  1. jtimon commented at 2:12 pm on December 1, 2015: contributor

    This improves concurrency by not locking CTxMemPool every time CBlockPolicyEstimator is used (although as said this is incomplete and the concurrency improvements can be continued), so it may have a positive impact on performance. But I haven’t done any benchmark or test.

    My original plan was to do this at once while encapsulating the global minRelayTxFee, but relay policy encapsulation is not welcomed at this point and now it would be more disruptive to completely decouple CTxMemPool from CBlockPolicyEstimator than it used to be when first coded this many months ago. We can take the first steps instead of waiting to do it at once, and that would hopefully prevent the code from evolving to something where is even harder to make this happen. Although @morcos thinks that CBlockPolicyEstimator should depend on CTxMemPool and I disagree on that, we both agree that CTxMemPool should not depend on CBlockPolicyEstimator. This PR reduces CTxMemPool’s dependency on CBlockPolicyEstimator.

  2. Mempool: Decouple CBlockPolicyEstimator from CTxMemPool e2a99575df
  3. Mempool: Make possible to call the estimator without knowing about the mempool f4bc7a25ff
  4. Locks: Mempool: does mempool need to wait for estimations? 850b186135
  5. Mempool: Improve mempool's concurrency
    ...while starting to decouple CTxMemPool from CBlockPolicyEstimator
    cfbe7029d1
  6. jtimon force-pushed on Dec 1, 2015
  7. jtimon closed this on Dec 1, 2015

  8. dcousens commented at 1:54 am on December 2, 2015: contributor
    @jtimon any reason for close?
  9. jtimon commented at 3:21 am on December 2, 2015: contributor
    It is incomplete and I know from past experience that it will be very expensive to maintain if not merged fast. I’m happy to complete and reopen it if/when there’s interest in doing this, but it didn’t seem to be the case at this point from the reactions I got from the few people I asked for review. I will complete it in my own personal branch on top of 0.12 once it is released, and then periodically forward-port that branch to 0.13, etc. I will always be happy to upstream things from that branch to Bitcoin Core, but there’s no reason for me to keep rebasing disruptive patches on top of the moving target that is bitcoin/master and wasting review time unless I believe they have reasonable chances of getting merged while opened. Nothing seems to indicate that is the case now.
  10. dcousens commented at 3:39 am on December 2, 2015: contributor
    No worries :+1:, thanks for the response. Indeed bitcoin/bitcoin is fast moving lately.
  11. MarcoFalke locked this on Sep 8, 2021


jtimon dcousens


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 18:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me