Calling check_timers() on every iteration causes a massive perfomance regression
This was reported to XQuartz in https://github.com/XQuartz/XQuartz/issues/156, and I bisected the perfomance regression to:
commit ac7a4bf44c68c5f323375974b208d4530fb5b60f (HEAD, refs/bisect/bad)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Apr 15 15:40:03 2018 +0100
os/WaitFor: Check timers on every iteration
Currently we only check timer expiry if there are no client fd (or
other input) waiting to be serviced. This makes it very easy to starve
the timers with long request queues, and so miss critical timestamps.
The timer subsystem is just another input waiting to be serviced, so
evaluate it on every loop like all the others, at the cost of calling
GetTimeInMillis() slightly more frequently. (A more invasive and likely
OS specific alternative would be to move the timer wheel to the local
equivalent of timerfd, and treat it as an input fd to the event loop
exactly equivalent to all the others, and so also serviced on every
pass. The trade-off being that the kernel timer wheel is likely more
efficiently integrated with epoll, but individual updates to each timer
would then require syscalls.)
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I have not yet profiled this to determine what about check_timers() is so expensive.