The "Running N tests" header re-sources every test file and re-runs every data provider (671ms over 240 files)

[Chemaclass]

Summary

Printing "Running N tests" sources the whole suite a second time, and runs every data provider a second time, before the run starts.

Measured

The counting pass over this repo's 240 test files costs 671 ms on macOS arm64, bash 3.2.57: 487 ms of nested subshells and 184 ms of re-sourcing. That is before any data provider executes, and 44 provider annotations in the suite do execute inside it.

Current behavior

bashunit::helper::find_total_tests, src/helper/discovery.sh:225-275, called from src/console/header.sh:36-46:

file_count=$( (
  source "$file"
  all_fn_names=$(compgen -A function)
  filtered_functions=$(bashunit::helper::get_functions_to_run "test" "$filter" "$all_fn_names")
  ...
  done <<<"$(bashunit::helper::execute_function_if_exists "$_BASHUNIT_PROVIDER_FN_OUT")"
) )

A double subshell per file, which sources the file and runs its providers. The runner then sources everything again (src/runner/discovery.sh:96, :143, :146, :148) and runs the providers again (src/runner/exec.sh:184-188).

It is skipped only under --parallel --simple (src/console/header.sh:38-40).

Expected behavior

Count provider-free files statically. bashunit::helper::build_provider_map (src/helper/provider.sh:29-100) already walks every line of the file with awk, and is memoized by path (:44-46) and deliberately pre-warmed in the parent so its cache survives into the runner (see the comment at src/console/header.sh:42-44). Extending that same awk pass to also emit top-level test_* names adds no fork. The count is then the names surviving get_functions_to_run (src/helper/discovery.sh:132-159).

Files whose provider map is non-empty keep the sourcing fallback, since a provider's row count is only knowable by running it. In this suite that leaves roughly 85% of files counted without a fork.

The risk is a test function a static scan cannot see, defined through eval, a loop, or a nested source. Then the header would disagree with the run. The gate for this change should be a differential over every file in tests/, plus several --filter and --exclude-filter values, requiring the old and new counts to be identical.

Whatever lands must preserve exactly what the count includes today. It ignores --tag, because tags are applied later in the runner (src/runner/discovery.sh:153-164).

[Chemaclass]

The provider-map cache does not survive into the runner, and that is most of the cost

The comment at src/console/header.sh:42-44 says the count pass pre-warms build_provider_map in the parent so the cache survives into the runner. Measured, it survives for exactly one file.

_BASHUNIT_PROVIDER_MAP_SCRIPT (src/helper/provider.sh:36, :44, :48) is a scalar, so the cache holds one entry. The count pass walks every file and overwrites it each time, leaving only the last. The runner then misses for all the others.

Census over 40 files on macOS arm64, bash 3.2.57:

Run	awk execs	per file
Header on	120	3
BASHUNIT_SHOW_HEADER=false	80	2

src/helper/provider.sh:98 fires twice per file with the header on: once for the count pass, once for the runner. 39 of 40 files pay the scan twice.

Wall cost of the whole count pass, same fixture: 2052 ms with the header against 1563 ms without, so 12.5 ms per file, about 40% of the 20 to 32 ms per-file cost. Larger than the 671 ms over 240 files quoted above, which measured only the subshell and re-source and excluded the awk scans.

So there are two separable wins here, and the cheap one is worth doing regardless of the static-count work:

1. Make the provider-map cache hold more than one entry, or pre-warm it in the order the runner will consume it. That alone removes one awk per file.
2. The static count for provider-free files, as described above.

[Chemaclass]

Done in #1357 (merged).