1

I tried implementing multi-threading to do below square() operation on a number. But it is taking too much time when compared to scenario where multi-threading is not used.

Please check the code below and the corresponding time taken to execute

import datetime
import time
from concurrent.futures import ThreadPoolExecutor
import multiprocessing

def square(x):
    #time.sleep(2)
    print("The result is:: %s\n" % str(x*x))

nums = [1,2,3,4,5]
dict = {}
dict[1] = 10
dict[2] = 20
dict[3] = 30
start = datetime.datetime.now()

# time taken = 41 ms
for index, value in dict.items():
    square(value)

# time taken= 1730 ms
with ThreadPoolExecutor(max_workers=5) as executor:
    for index,value in dict.items():
        executor.submit(square, value)


# time taken = 1034 ms
with ThreadPoolExecutor(max_workers=5) as executor:
    executor.map(square, dict)

# time taken : 35860 ms
a_pool = multiprocessing.Pool()
a_pool.map(square, dict)


end = datetime.datetime.now()
print("Total time::", end - start)

A few questions:

  1. Why multi-threading is taking more time than normal process without threads?
  2. I read that multi-processing is faster than multi-threading. But in above example, it is taking more time than multi-threaded environment.
  3. Any suggestions to implement which can enhance the performance and can cause concurrent executions?

Note: The above is just a pseudo code. I wanted to implement multi-threading in my actual project but there also, it is showing the same behavior.

martineau
  • 119,623
  • 25
  • 170
  • 301
  • Just an aside - you should use `time.perf_counter()`. – OTheDev Apr 27 '22 at 06:53
  • It's very likely that the GIL is the cause of this unexpected behavior, so I've closed this question as a dupe of "What is the GIL." That's maybe a contentious decision so if folks strongly object, please feel free to reopen! – Adam Smith Apr 27 '22 at 06:54
  • Is this run on windows or linux (or Mac)? – ilmarinen Apr 27 '22 at 07:13
  • 1
    @Adam: I agree with your reasoning. Multi-threading isn't appropriate for compute-bound tasks due of the GIL, and is best for ones that are I/O-bound. The reason being there's no real concurrency unless one or more of the tasks are waiting for I/O to complete. – martineau Apr 27 '22 at 08:00
  • Thanks for the answer. @ilmarinen, this is running on linux. – CodeSleepEat Apr 27 '22 at 08:32
  • CodeSleepEat: What "answer" from @ilmarinen are you talking about? – martineau Apr 30 '22 at 01:30

0 Answers0