The EraseForBlock branch in the txorphan harness could produce a block with 1000 transactions in it, each with potentially up to 200,000 inputs, resulting in way too many map lookups. This was producing inputs that were taking 2 seconds or longer per iteration, which is too long.
Fix by only adding transactions to the block up to the block weight limit. This matches production behavior, as EraseForBlock is only called on a newly connected block.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35289.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | maflcko, sedited, instagibbs |
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
Can be tested by running the harness on this input: txorphan-timeout.txt
FUZZ=txorphan ./fuzzbuild/bin/fuzz txorphan-timeout.txt
On master, it should take more than 2 seconds and with this PR significantly less.
Here's the flamegraph:
<img width="1200" height="406" alt="solution-6d51c5dbc793ebfce64809c2546ba34baf05bdd4" src="https://github.com/user-attachments/assets/5ab65615-6096-4581-b785-faba59d89f07" />
lgtm ACK 004a7e3cfbc5b2118536651d2201cf8b72c87736
ACK 004a7e3cfbc5b2118536651d2201cf8b72c87736
ACK 004a7e3cfbc5b2118536651d2201cf8b72c87736
Don't love "EraseForBlock" but this seems more realistic at least
post-merge tACK 004a7e3cfbc5b2118536651d2201cf8b72c87736
I used txorphan-timeout.txt and ran:
FUZZ=txorphan build_fuzz/bin/fuzz -runs=1 fuzz_input/
Prior to this patch:
Done 2 runs in 10 second(s)
real 0m11.047s
user 0m10.505s
sys 0m0.165s
After applying this patch:
Done 2 runs in 0 second(s)
real 0m0.907s
user 0m0.260s
sys 0m0.193s