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/31182.

Reviews

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #31257 (ci: make ctest stop on failure by furszy)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Using tmpfs for temporary test directories can potentially speed up tests a lot, something to be wary for is that it significantly increases memory usage as well (no idea if this is a problem for the current CI).

something to be wary for is that it significantly increases memory usage as well (no idea if this is a problem for the current CI).

I'd say the memory increase shouldn't matter, because on modern distros the default temp dir is already a tmpfs. So if memory was an issue, then running the tests normally (outside the CI) would already lead to issue reports. (I haven't seen any, but I may be missing some).

So I think it is fine to enable this by default without an off-switch for now. If there is need, a new env var toggle can be added to disable it.

I'd say the memory increase shouldn't matter, because on modern distros the default temp dir is already a tmpfs. So if memory was an issue, then running the tests normally (outside the CI) would already lead to issue reports. (I haven't seen any, but I may be missing some).

i don't think anyone runs the tests in low-memory/disk conditions 😄 i've had some issues on custom RISC-V hardware in the past, but nothing significant enough to create an issue about. At least the CI will start with a clean slate every time so no cruft accumulates in tmpfs.

(force pushed to fix a type bug in the modified Python code, discovered by the Windows CI. I wish this code was written in Rust or another type-safe language, so that issues like this are caught at compile-time, but this can be done in a follow-up)

(see comment below for results).

What is this referring to?

(see comment below for results).

What is this referring to?

I was still running the commit (and master) twice each for all CI tasks, but I couldn't find any difference at all.

I checked that the folder is correctly picked up and used by the tests, so I guess modern storage is fast enough to not make a difference? Alternatively, there is an issue I was missing.

It would be good if someone else double checked the code and whether there is a performance difference at all.

For reference (showing no difference):

• Current master

• This pull

That is odd, and a little disappointing. The code appears correct to me.

I was wondering whether tmpfs according to docker might just mean "ephemeral" (but still disk-based), but it appears that it it is both ephemeral and ramdisk based as per the underlying filesystem tmpfs.

I will run the CI on my own self-hosted runner, and see what sort of numbers I get from it...

My plan is to get hold on an HDD (or some other slow storage) and try with that. Any effect should be more pronounced on slower persistent storage.

I tested it on a Pi 4B, with 4GB of memory, Ubuntu 24.04, using 1 CPU thread: CCACHE_MAXSIZE=1500M MAKEJOBS="-j1" FILE_ENV="./ci/test/00_setup_env_native_nowallet_libbitcoinkernel.sh" /usr/bin/time --format='%U+%S %e (%E)' ./ci/test_run_all.sh. However, I couldn't find any difference either. Moreover, with MAKEJOBS="-j4", this pull performed worse than the commit prior to it (55min vs 1h5min).

Not sure why, but I guess modern Linux will cache the file IO sufficiently to not make a difference for this projects' CI? Whereas using tmpfs with limited memory may be a pessimization due to the overhead of swap?

Closing for now, until someone can show how to actually improve the performance with this.