looking forward to seeing the impacts of those changes.

Well I think it'll be hard to see in a single CI run because the fluctuations are huge (several minutes from 1 run to another).
That said, 28min on the windows job is something I've rarely seen.

For reference, on my laptop it reduced the duration from 14min to 11m30

And somehow the macos jobs and some of the linux ones are crazy high....

Starting to look good pretty good. (need to do some clean-up now)

It's now a fixture with a session scope but it's not used if we don't run the test suite for the whole package. It seems to be the same issue that we had for global_random_seed. We probably need to make a plugin if we want to be able to use it in all situations.

It's now a fixture with a session scope but it's not used if we don't run the test suite for the whole package.

I tried it locally and it seems to work even when limiting the tests to a given submodule / test pattern. I tried:

pytest -n 4 -v sklearn/ensemble -k test_map_to_bins

and I could check that it is actually limiting the number of threads to 2 (on a machine with 8 cores) by raising an exception with the content of threadpoolctl.threadpool_info() in the test.

Here are the Azure timings of this PR (left) vs the last run of #25930 (right):

This is a uniform improvement although the slowest macos run was not improved (but not degraded either).

Smaller yet also uniform improvements on the Cirrus CI runs as well (this PR left vs #25930 right).

For the wheel builder workflow on github actions:

• 36 min total duration on this PR
• 58 min total duration on DEBUG CI durations #25930

although I do not understand those numbers because the individual "Build wheel for..." jobs do not seem to be uniformly improved: many have the same duration and some are degraded.

I redid the experiment described in #25918 (comment) locally with the new method (using pytest_configure instead of the session scoped auto-scoped fixture) and it still works as expected.

@lesteve I think your concern was taken into account and based on the above timing results I think we can merge.

Let me just check if the conftest is discovered in the wheel builder

Let me just check if the conftest is discovered in the wheel builder

All builds are red in #25930 so that shows that pytest_configure is run in wheels as well and we can merge right?

Yep.

Actually I just realized that the jobs of the wheel builder don't use pytest-xdist so it's expected that the durations are not impacted since the configuration in pytest_configure does the same thing as the previous configuration with the env vars.

OK let's merge this one, thanks a lot!

With this PR, most CI jobs will be running with single threaded OpenMP/BLAS. I think only the wheel building jobs still runs with multiple threads because it does not install pytest-xdist.

Can we remove pytest-xdist from one of the CI jobs to have a little more coverage for running with multiple threads?

With this PR, most CI jobs will be running with single threaded OpenMP/BLAS

It was already the case for OpenMP, since _openmp_effecive_n_threads returned 2 and the number of xdist workers is >= 2 (the ratio being 1).
This PR treats BLAS similarly to avoid oversubscription.

I'm not opposed to removing pytest-xdist from 1 job but we must do it in a fast job because the reason of this PR was that the CI duration was becoming more and more frustrating :)
I guess Linux pylatest_pip_openblas_pandas is a good candidate

I guess Linux pylatest_pip_openblas_pandas is a good candidate

I'm okay with removing pytest-xdist from this one job. (I'm also curious to see how the runtime changes).

+1 but let's be very explicit (in a comment) as to why we remove it then.

I opened #25943