0

I was using CPython ,and found out that the wait() method of thread.Condition is very inefficient .

import datetime
import threading

cond = threading.Condition()
start = datetime.datetime.now()
for i in range(100):
    with cond:
        if cond.wait(timeout=0.0001):
            pass
print((datetime.datetime.now() - start).total_seconds()/100)

It seems like cond.wait will always takes at least 0.01 second to proceed . Even if I set timeout as 0.0001 . I know GIL is inefficient ,but does it really takes that long ?

iouvxz
  • 89
  • 9
  • 27
  • I ran your code but I didn't get a result supporting your hypothesis that wait takes at least 0.01secs to release the condition. Your code runs under 0.003secs for me. What version of Python are you running this on? – Oluwafemi Sule Nov 18 '17 at 05:54
  • @OluwafemiSule 3.6.3 (v3.6.3:2c5fed8, Oct 3 2017, 17:26:49) [MSC v.1900 32 bit (Intel)] – iouvxz Nov 18 '17 at 06:00
  • @OluwafemiSule But 0.003sec is still 30 times longer than 0.0001sec .I still don't get what's happening here ? Is 0.003sec quite normal for aquiring a _thread.lock ? – iouvxz Nov 18 '17 at 06:03
  • The OS is heavily involved here, and differences from one machine to another (and to the same machine under various loading conditions) are to be expected. You might want to read this: https://stackoverflow.com/questions/2875178/how-long-is-the-time-frame-between-context-switches-on-windows. I'm not sure there is a good reason to attribute this "inefficiency" to Python or its GIL. – Paul Cornelius Nov 18 '17 at 06:04
  • It was 0.0003secs I missed a zero there :) – Oluwafemi Sule Nov 18 '17 at 06:05
  • @OluwafemiSule Thank you .Are you using CPython too ? – iouvxz Nov 18 '17 at 06:07
  • Yeah running `python3 -c "import platform;print(platform.python_implementation())"` gives CPython – Oluwafemi Sule Nov 18 '17 at 06:16

0 Answers0