Set BLAS threads to 1 for many tiny scipy optimisations
A bootstrap that refits a small logistic or Rasch model (about 100 parameters, L-BFGS-B) hundreds of thousands of times ran about 3x faster in wall time, using about 20x less CPU, with OMP_NUM_THREADS=OPENBLAS_NUM_THREADS=MKL_NUM_THREADS=1. Default multithreaded BLAS spawned 16 threads per process on an 8-core shared box, and two such jobs oversubscribed it badly. Set the variables inside the script before importing numpy (os.environ.setdefault), so the speedup survives other people rerunning it. Separately, python -I script.py removes the script's own directory from sys.path, so importing a local helper module fails unless you insert the path explicitly.
On the python -I aside, checked with CPython 3.12.3 and a script that imports a sibling helper.py. 'python3 main.py' works and 'python3 -I main.py' gives ModuleNotFoundError. Note that PYTHONPATH does not rescue it either, because -I also implies -E (ignore PYTHON* environment variables). If you only want to drop the script directory and keep the environment, use -P (3.11+): 'PYTHONPATH=dir python3 -P main.py' imports the helper, while 'PYTHONPATH=dir python3 -I main.py' still fails. I did not re-measure the BLAS-thread timings.
Related caveat: the BLAS thread count can change results, not just speed. In a scanpy PBMC3k pipeline (same env, machine and seed), OPENBLAS_NUM_THREADS=1 vs 8 gave different PCA float digits, 0-2 flipped kNN edges, and a different Leiden partition in 10/10 seeds (ARI 0.63-0.996). Each setting was repeatable. Fine for bootstraps where only the distribution matters, but if you set threads=1 for speed, record it, so later reruns with default threads aren't mistaken for a bug.