[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Change by Raymond Hettinger : -- assignee: -> docs@python components: +Documentation -Windows nosy: +docs@python type: performance -> behavior ___ Python tracker ___

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Eryk Sun added the comment: > Given that extra info, I'd say we're fine to document that our timeouts > can't do any better than the OS, which "for example, is typically > around 15ms on Windows", and recommend using non-blocking calls > instead. The 15.625 ms resolution limit is fine, as

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Steve Dower added the comment: Given that extra info, I'd say we're fine to document that our timeouts can't do any better than the OS, which "for example, is typically around 15ms on Windows", and recommend using non-blocking calls instead. --

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Eryk Sun added the comment: See the related discussion in bpo-41299. The system interrupt period can be lowered to 1 ms with timeBeginPeriod() -- or lower with undocumented NtSetTimerResolution(). This affects the resolution of dispatcher waits such as Sleep() and WaitForSingleObject(), as

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Terry J. Reedy added the comment: Another possibility might be to not use the Windows timeout clock, at least not for short timeouts. The following shows that tk does about 970 1 millesecond timeouts in 1 second (on my machine). --- import tkinter as tk root = tk.Tk() cbid = None cbcount =

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Steve Dower added the comment: Agreed with not putting platform-specific details everywhere, but in this case we can probably have a generic wording for "Blocks for `timeout` seconds as best as is available on the current operating system". It is a general problem across all timeouts, so

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

STINNER Victor added the comment: I dislike the idea of documentation the Windows clocks in the queue documentation, it's not the right place. I dislike the idea of documentating Windows "internals" in the Python documentation. You should see Python as a "thin wrapper" to the operating

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Eryk Sun added the comment: Changing the system timer resolution doesn't appear to help, given the current design combined with what looks like a bug in Windows (at least in Windows 10). We can set the system clock resolution below a millisecond via NtSetTimerResolution. I tested at 0.4882

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Paul Overing added the comment: Thank you to everyone for looking at my issue esp Josh.r for the detailed response. I now understand the issue and I just wanted to bring it to the group's attention for everyone's benefit. Vstinner is correct; Linux is my solution as it is my production

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Josh Rosenberg added the comment: Victor, that was a little overboard. By that logic, there doesn't need to be a Windows version of Python. That said, Paul doesn't seem to understand that the real resolution limit isn't 1 ms; that's the lower limit on arguments to the API, but the real

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

STINNER Victor added the comment: > It makes the windows queue.Queue implementations with timeouts unusable in > low latency environments and should be documented as such. As it is slow and > highly variable. Well, it seems like you have a solution which is called Linux, no? --

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Paul Overing added the comment: Thank you for your quick response. But 1ms resolution or not, 14.5ms does not seem reasonable given that in Ubuntu it is 0.049ms. Ubuntu is on average 295x faster. Also the variability in times is much higher in Windows max/avg = 9.547, avg/min = 8.69.

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

STINNER Victor added the comment: > Victor or Steve, do you know the resolution of perf_counter() and monotonic() > on Windows? You can use: >>> time.get_clock_info('perf_counter') namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True,

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Raymond Hettinger added the comment: Victor or Steve, do you know the resolution of perf_counter() and monotonic() on Windows? -- nosy: +rhettinger, vstinner ___ Python tracker

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

New submission from Paul Overing : I have found that using timeout with a python queue.Queue() results in an average delay of 14.5ms in Windows over Ubuntu in python 3.6.5/3.7, I subtracted the 1 ms timeout. I have also tried datetime.datetime.now() to measure the time, with similar