test: poll more frequently in sync helpers and RPC connection wait #36439

pull ViniciusCestarii wants to merge 1 commits into bitcoin:master from ViniciusCestarii:speedup-test-framework changing 2 files +6 −5

ViniciusCestarii commented at 3:27 PM on October 5, 2026: contributor
Tested on my x86-64 machine:
- Wall time (-j=18): 110.8s to 96.4s (−13%)
- Accumulated: 1715s to 1369s (−20%)
Also compared the CI on my fork (time for test_runner.py runtime):
- macOS native: 1287s to 1175s (-9%)
- 32 bit ARM: 776s to 690s (-11%)
- Windows native, VS: 1456s to 1252s (-14%)
- previous releases: 930s to 786s (-15%)
- No wallet: 614s to 572s (-7%)
- Alpine (musl): 1958s to 1970s (+0.6%)
Sanitizer jobs are left out because they vary too much between runs.

Alpine (musl) uses --usecli, so more frequent poll creates a new bitcoin-cli process each time, making it not faster with these changes. Also tried locally with --usecli: from 2060s to 2051s accumulated.
DrahtBot added the label Tests on Oct 5, 2026
DrahtBot commented at 3:28 PM on October 5, 2026: contributor


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



External sites
- Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36439
- Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36439.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36439#author-ralph


Reviews

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

in test/functional/test_framework/test_node.py:357 in 12caa3325d outdated

 352 | @@ -353,8 +353,8 @@ def create_new_rpc_connection(self, *, mode="AUTO", client_timeout=None):
 353 |  
 354 |      def wait_for_rpc_connection(self, *, wait_for_import=True):
 355 |          """Sets up an RPC connection to the bitcoind process. Returns False if unable to connect."""
 356 | -        # Poll at a rate of four times per second
 357 | -        poll_per_s = 4
 358 | +        # Poll at a rate of twenty times per second
 359 | +        poll_per_s = 20

maflcko commented at 7:24 AM on October 6, 2026:

nit: Use a deadline time here as well?

ViniciusCestarii commented at 12:41 PM on October 6, 2026:

Makes sense, Done in 88d40ec15510a8d029c1eaffbae9c068da18f5f9

in test/functional/test_framework/test_framework.py:720 in 12caa3325d outdated
```
 716 | @@ -717,7 +717,7 @@ def sync_blocks(self, nodes=None, wait=1, timeout=60):
 717 |              "".join("\n  {!r}".format(b) for b in best_hash),
 718 |          ))
 719 |  
 720 | -    def sync_mempools(self, nodes=None, wait=1, timeout=60, flush_scheduler=True):
 721 | +    def sync_mempools(self, nodes=None, wait=0.05, timeout=60, flush_scheduler=True):
```
maflcko commented at 7:24 AM on October 6, 2026:

Pretty sure I tried this one in the past, but it didn't result in a speed-up. I guess back then the trickle relay was used, and dominated. Now, the immediate tx relay is used for most tests and it can help.

ViniciusCestarii commented at 1:23 PM on October 6, 2026:

Interesting, makes sense.
maflcko commented at 7:27 AM on October 6, 2026: member

haven't tested this, but it seems fine. I wonder if someone wants to create some plots to show this is an improvement (and to see the performance plot around the values). Also, I think functional tests are run at double saturation (2*nproc) sometimes, so it would be good to check this doesn't regress either.
test: poll more frequently in sync helpers and RPC connection wait 88d40ec155
ViniciusCestarii force-pushed on Oct 6, 2026
ViniciusCestarii commented at 1:20 PM on October 6, 2026: contributor

Thanks @maflcko for reviewing. Force-pushed 88d40ec15510a8d029c1eaffbae9c068da18f5f9 addressing #36439 (review)

I think functional tests are run at double saturation (2*nproc) sometimes, so it would be good to check this doesn't regress either.

By what I found, only the job "test ancestor commits" does it. Agree it's worth checking.

create some plots to show this is an improvement (and to see the performance plot around the values)

Will do.
ViniciusCestarii commented at 7:08 PM on October 6, 2026: contributor
I benchmarked these changes on my x86-64 machine with 20 logic processors:

<img width="960" height="790" alt="image" src="https://github.com/user-attachments/assets/0c346527-71bb-4288-9ca2-22eaf5240f17" />
- master is the baseline and w0.05 is this PR.
- rpc20 is only the wait_for_rpc_connection change, sync0.05 is only the sync changes.
- w0.X sets both the sync wait and the RPC connection poll interval to X seconds.
- Wall time is how long the whole suite took, running the tests in parallel.
- The sum is the total of each test's own wall-clock duration, measured while running in parallel.
Most of the gain comes from the sync change and RPC poll change adds a smaller one on top. Below 0.05 there is no further improvement and at -j40 polling faster (w0.01) starts to cost more than it saves, so 0.05 looks like the right value.

It'd be great if others could run it too.

I measured this with this script: https://gist.github.com/ViniciusCestarii/72216066d3707b41b3b5b2292b07055b usign the command:
```
python3 pollbench.py --jobs 20,40 --runs 5 --variants master=1:4,w0.25=0.25:4,w0.1=0.1:10,w0.05=0.05:20,w0.025=0.025:40,w0.01=0.01:100,sync0.05=0.05:4,rpc20=1:20
```
I used AI to help me make this benchmark script and plot the data.

Contributors

Labels

test: poll more frequently in sync helpers and RPC connection wait #36439

External sites

Reviews