net processing: Add ibd check before processing block for txdownloadman #34054

1. 
   sedited commented at 9:06 am on December 12, 2025: contributor

   Calculating the rolling bloom filters for the txorphanage takes some CPU time from the scheduler thread. This can be observed for example in this flamegraph, where handling the filter takes about 2.6% of total time (and most of the scheduler thread’s time).

   During ibd the entries in the tx download bloom filter are just continuously rolled over and aren’t consumed, since no mempool entries are created by incoming transactions from peers during ibd. The mempool does accept transactions via RPC, or the wallet at the time, however these don’t interact with the orphanage and the txdownloadman, because adding anything to those is guarded by IsInitialBlockDownload() checks as well.

   We’re usually latching ibd to false a few blocks before catching up to the tip, so this should also not significantly degrade the performance of the filter once fully caught up.

2. DrahtBot added the label P2P on Dec 12, 2025
3. 
   DrahtBot commented at 9:06 am on December 12, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34054.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   No conflicts as of last run.

4. 
   maflcko commented at 10:17 am on December 12, 2025: member

   During ibd the entries in the tx download bloom filter are just continuously rolled over, and aren’t consumed, since no mempool is maintained at the time.

   I think this could be clarified a bit, why this is safe. My understanding is that a mempool does exist and is maintained (albeit it will normally be empty). The mempool will also happily accept transactions via RPC, or the wallet. However, this is fine, because they don’t interact with the orphanage and the txdownloadman, because adding anything to those is guarded by IsInitialBlockDownload() checks as well?

   Ref:

   https://github.com/bitcoin/bitcoin/blob/8da8ff30a57f0fe7f627d121c5e40466f1ecb0b2/src/net_processing.cpp#L4258-L4268

   and

   https://github.com/bitcoin/bitcoin/blob/8da8ff30a57f0fe7f627d121c5e40466f1ecb0b2/src/net_processing.cpp#L3987-L3990

5. 
   sedited commented at 8:21 pm on December 15, 2025: contributor

   Re #34054 (comment)

   I think this could be clarified a bit, why this is safe.

   Thanks, that was not precise. Slightly reworded your explanation and added it to the pull request description. I was curious if the ibd check might cause a performance regression, since we’re probably triggering fewer de-allocs on the scheduler thread. I tried to get some results in benchcoin. The results were kind of mixed, but there is clearly no more work being done through the txdownloadman during ibd.

6. 
   maflcko commented at 12:32 pm on December 16, 2025: member

   fewer de-allocs on the scheduler thread.

   I think this patch does not change whether the event is run on the scheduler thread, or not, but rather if the event runs faster in the scheduler thread with the early return. So I think this should not move destructor calls between threads. Or am I missing something?

7. 
   sedited commented at 12:52 pm on December 16, 2025: contributor

   Re #34054 (comment)

   but rather if the event runs faster in the scheduler thread with the early return.

   Yes, and I was curious if this might change where the final decrement for the block’s shared pointer happens.

8. 
   maflcko commented at 1:31 pm on December 16, 2025: member

   Oh, I see. I guess if the behavior should be enforced at compile-time, the blocks could be std::moved into the event
9. net processing: Check if we are in ibd before processing block for txdownloadman 42dc1725b9
10. DrahtBot added the label Needs rebase on Dec 16, 2025
11. sedited force-pushed on Dec 16, 2025
12. 
    sedited commented at 3:26 pm on December 16, 2025: contributor

    Rebased 2233420fcff7c9c3d7d5727880a8ae1e6173eb89 -> 42dc1725b978329e0808db5e2c3a64c038c35de3 (txdownloadman_ibd_check_0 -> txdownloadman_ibd_check_1, compare)

    • Fixed conflict with #30214
13. DrahtBot removed the label Needs rebase on Dec 16, 2025

Contributors
sedited DrahtBot maflcko

Labels
P2P