Yury Selivanov added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31539> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
