In issue 681167, I found base::WaitableEvent to be slow on Mac, and so I rewrote it for some considerable performance improvements. One of the performance metrics that was examined was //ipc:ipc_perftests. While the improvements to WaitableEvent were noticeable on //base:base_perftests micro-benchmarks, improvement did not show up in ipc_perftests. When I investigated further in Instruments, I noticed that the bulk of CPU time was dominated by the internals of CFRunLoop.

As part of  issue 356804 , specifically commit 3669d7d8f64445139731e73da773dbd2d4a81afb, the factory function MessageLoop::CreateMessagePumpForType() for TYPE_DEFAULT was changed from using MessagePumpDefault (a small wrapper around WaitableEvent) to MessagePumpCFRunLoop. The goal of this was to enable timer coalescing on the timers used for scheduling the delayed work source, to reduce the number of idle wakeups. It is not clear from the bug how significant this change actually is to power consumption (it was and still is hard to measure, but  issue 388360  indicates there is some performance impact).

The use of timers in MessagePumpMac seems to be ultimately unnecessary. The MessageLoop itself has no mechanism by which it schedules or arranges timers on behalf of something like base::Timer -- those are merely delayed posted tasks. The timer used by MessagePumpMac is set to fire at the next_delayed_work_time specified by MessagePump::Delegate::DoDelayedWork() (which is the MessageLoop) or MessagePump::ScheduleDelayedWork().

An alternative to this would be to call CFRunLoopRunInMode() or -[NSRunLoop runMode:beforeDate:] with the next computed work time, rather than always invoking with distantFuture. It has already been observed and somewhat mitigated in  issue 511406  that scheduling CFTimers in a run loop is expensive, and this could completely eliminate that. This would remove the opportunity to use timer coalescing, though. In addition, doing this would change the relative priority of work sources in the CFRunLoop.

That alternative would still leave MessageLoop::TYPE_DEFAULT using a CFRunLoop implementation, which as noted above is rather heavyweight. Internally there are multiple pthread_mutex_t's that must each be acquired: every run loop object, mode object/array, and source/observer/timer object has its own lock that must be taken before scheduling or invoking the work source callout. This lock acquisition and the re-shuffling of the internal sources arrays are what dominate the ipc_perftests benchmarks. It would be ideal if we could avoid CFRunLoop wherever it is not necessary because it is so heavyweight. Reverting 3669d7d8f644 and using MessagePumpDefault for MessageLoop::TYPE_DEFAULT would certainly do this, and it would now have the benefit of the performance improvements made to WaitableEvent.

However if we assume that timer coalescing is beneficial, then that could lead to a power or idle wakeup regression (assuming that switching to a lighter-weight MessagePump wouldn't cause it to be a wash or net-beneficial). Yet there is still a way to both avoid using CFRunLoop and to take advantage of timer coalescing: Internally, CFRunLoopTimerSetTolerance() sets the leeway on a DISPATCH_SOURCE_TYPE_TIMER using _dispatch_source_set_runloop_timer_4CF(). Libdispatch eventually sets this tolerance value on a kevent EV_TIMER using the NOTE_LEEWAY filter flag. It would be relatively trivial to implement a new MessagePumpKqueue that had overhead equivalent to MessagePumpDefault, but with the potential to do timer coalescing. The main difference would be rather than using an explicit timeout to kevent64() when waiting for events, an EV_TIMER event would be placed on the kqueue() to trigger delayed work with leeway.

But it may not be actually necessary to write MessagePumpKqueue. Instead, it may be enough to simply lower the scheduler priority of the thread and/or task (in the case of renderer processes). Ultimately timers and other event sinks get represented by a wait queue in the kernel, and the wait queue priority classes are shared amongst both those types of waitable objects (see 10.12/xnu-3789.1.32/osfmk/kern/kern_types.h wait_timeout_urgency_t). The effective priority class is hierarchical from task > thread > wait queue object, meaning that if an entire task or thread has priority of background, then all of its timers by default should too. The main difference would be that MessagePumpMac specifies an explicit timer leeway -- how much time the deadline can be shifted -- rather than setting a priority and letting the system schedule it.

I propose that we switch back to using MessagePumpDefault for MessageLoop::TYPE_DEFAULT in an A/B experiment. We can then examine metrics (probably locally using Activity Monitor's "Idle Wakeups" metric) to determine if doing so has caused a performance regression. If not, then we're done -- the TYPE_UI loop obviously has to be NSApplication/CFRunLoop-backed, and TYPE_IO will continue to be backed by MessagePumpLibevent. But if a regression is observed, we can implement MessagePumpKqueue to recreate the timer leeway coalescing done by MessagePumpMac.