Initial benchmarking with more extensive use of threadpoolctl in scikit-learn suggest that the overhead of setting limits can be considerable. While there may be ways to improve that within joblib and/or scikit-learn, having threadpoolctl itself be faster would help all users.
Some ideas:
- Microoptimizations.
- Caching the
ThreadpoolController, and invalidating it when imports change.
- Caching individual
CDLL. This has the nice property that one can reasonably assume they never get unloaded, so you don't need invalidation logic.
- ... maybe more as I look at profiling results and think ...
Initial benchmarking with more extensive use of threadpoolctl in scikit-learn suggest that the overhead of setting limits can be considerable. While there may be ways to improve that within joblib and/or scikit-learn, having threadpoolctl itself be faster would help all users.
Some ideas:
ThreadpoolController, and invalidating it when imports change.CDLL. This has the nice property that one can reasonably assume they never get unloaded, so you don't need invalidation logic.