[llvm] [lit] Migrate lit to ThreadPoolExecutor (PR #212397)

[Prasoon Kumar via llvm-commits]

prasoon054 wrote:

Closing this out since the numbers just don't add up. The thread backend ended up consistently slower, and after digging into it, the evidence points to the same root cause on both macOS and Linux. The workload is dominated by syscalls rather than Python bytecode, and multiple threads keep contending for the single shared GIL under that load. I tried narrowing locking in the code, however that didn't make any meaningful difference. At this point it doesn't look like we can realistically fix it here.
There is some promising work happening in the CPython community around free threaded Python. [PEP 703](https://peps.python.org/pep-0703/) introduced an experimental free threaded build in Python 3.13, and [PEP 779](https://peps.python.org/pep-0779/) made it officially supported, though still non-default, configurable in Python 3.14. If free threaded CPython ever becomes the baseline for LLVM, it'd be great if someone revisited a thread based backend then since the bottleneck this PR hit is exactly the kind of problem free threading is meant to solve.
I'll be moving on to an asyncio based single process execution model for lit now.

https://github.com/llvm/llvm-project/pull/212397