Author yselivanov
Recipients germn, gvanrossum, pitrou, r.david.murray, vstinner, yselivanov
Date 2017-09-21.21:47:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1506030446.6.0.184602240334.issue31539@psf.upfronthosting.co.za>
In-reply-to
Content
> The performance issue was that the asyncio core loop was running in a loop
but did nothing because of time rounding. When the next event was in a few
nanoseconds, the e event burnt the CPU during <clock resolution> seconds.
It can be 15 ms on Windows or 1 ms when using poll() for example. It's not
just clock resolution, also the resolution of the selector.

Hm.  I glanced through the issues you linked, and it looks like it's a valid concern for a micro-benchmark.  But I don't see how a performance of a real-world application can be affected here.  IOW, the "self.time() + self._clock_resolution" line looks like an optimization for a particular micro-benchmark.  I'm sure we can construct another micro-benchmark that would benefit from "self.time() - self._clock_resolution".

I think we should value correctness more than micro-benchmarks.
History
Date User Action Args
2017-09-21 21:47:26yselivanovsetrecipients: + yselivanov, gvanrossum, pitrou, vstinner, r.david.murray, germn
2017-09-21 21:47:26yselivanovsetmessageid: <1506030446.6.0.184602240334.issue31539@psf.upfronthosting.co.za>
2017-09-21 21:47:26yselivanovlinkissue31539 messages
2017-09-21 21:47:26yselivanovcreate