[issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than multiprocessing.Pool.map() for fast function argument

Tobias Brink added the comment: I can confirm an overhead of 2 ms to 3 ms using a relatively recent Intel Core i5 CPU. I (personally) believe these 3 ms to be a pretty big overhead on modern computers and I also believe that it would be relatively simple to reduce it. I don't have much

[issue11324] ConfigParser(interpolation=None) doesn't work

New submission from Tobias Brink : The docs for Python 3.2 say that p = configparser.ConfigParser(interpolation=None) disables interpolation. Instead it gives this traceback when calling p.read(): Traceback (most recent call last): File "", line 1, in File "/us

[issue11324] ConfigParser(interpolation=None) doesn't work

Tobias Brink added the comment: I added a test but I am not too familiar with the Python test suite. Please check if the "test_init_takes_interpolation_none" test is necessary because the test suite also fails without it if my patch is not applied. Feel free to remove i

[issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than multiprocessing.Pool.map() for fast function argument

New submission from Tobias Brink : I tested the new concurrent.futures.ProcessPoolExecutor.map() in 3.2 with the is_prime() function from the documentation example. This was significantly slower than using multiprocessing.Pool.map(). Quick look at the source showed that multiprocessing sends

[issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than multiprocessing.Pool.map() for fast function argument

Tobias Brink added the comment: Playing around a bit I wrote the attached implementation which works with all iterables. -- Added file: http://bugs.python.org/file20826/new_processpoolexecutor.py ___ Python tracker <http://bugs.python.