➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author methane
Recipients Epic_Wink, Vojtěch Boček, asvetlov, methane, yselivanov
Date 2019-05-28.05:15:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1559020524.0.0.917326083276.issue35279@roundup.psfhosted.org>
In-reply-to
Content 
Current default value is decided in here:
https://bugs.python.org/review/21527/#ps11902

It seems there were no strong reason for current cpu_count * 5.
I think cpu_count + 4 is better default value, because:

* When people are using threadpool for CPU heavy job which releases GIL, workers >= cpu_count is good.
* When people are using threadpool for multiplexing I/O, best workers number is vary on the workload.  But I think 4~16 is good for typical case.



> This is amplified by the fact that the `concurrent.futures.ThreadPoolExecutor` threads are never killed, and are not re-used until `max_workers` threads are spawned.

Note that this is fixed by #24882.
History
Date User Action Args
2019-05-28 05:15:24methanesetrecipients: + methane, asvetlov, yselivanov, Vojtěch Boček, Epic_Wink
2019-05-28 05:15:24methanesetmessageid: <1559020524.0.0.917326083276.issue35279@roundup.psfhosted.org>
2019-05-28 05:15:23methanelinkissue35279 messages
2019-05-28 05:15:23methanecreate