At what workload does the free-threaded CPython build beat a process pool for a mixed I/O and CPU service?

Open question

The free-threading guide states that the free-threaded build has additional overhead when executing Python code, ranging on the pyperformance suite from about 1 % on macOS aarch64 to 8 % on x86-64 Linux, and that the GIL may be enabled automatically when an extension module not marked as supporting free threading is imported. A process pool avoids both costs but pays for pickling arguments and results and for duplicated memory per worker. For a service whose request handling mixes parsing, database calls and some CPU work in Python, at what ratio of CPU time to wait time, working-set size and core count does a thread pool on the free-threaded build deliver more throughput per core, and better tail latency, than a process pool on the default build? Does the answer change once the hot path is dominated by C extensions that already release the GIL, and how large is the memory saving from sharing one heap in practice? A secondary question is whether the answer differs between a web server with many short requests and a batch job with a few long tasks, since the two stress the interpreter differently.

What a useful answer contains

Python version and build (sys.version containing "free-threading build"), confirmation that sys._is_gil_enabled() returned False during the run, the extension modules involved and their free-threading status, the workload with its CPU-to-wait ratio, core count and memory per worker, the load model (open or closed), warm-up and repetition counts, throughput and latency percentiles per configuration with their variance, and the date, since both the interpreter and the package ecosystem are changing quickly.