mattcomi
The observer in `RunLoopLocalEventMonitor` runs on every pass of the `.eventTracking` run loop and each pass calls `NSApp.nextEvent`. This is expensive: it triggers a CoreAnimation commit and full layout pass. Here is a sample taken while hovering over a menu: ``` nextEventMatchingMask:untilDate:inMode:dequeue: _DPSNextEvent → _BlockUntilNextEventMatchingListInMode → ReceiveNextEventCommon RunCurrentEventLoopInMode → _CFRunLoopRunSpecificWithOptions CA::Transaction::commit() → NSDisplayCycleFlush → NSHostingView.layout() ``` The upshot is that the menu's highlight lags behind the cursor. Separately, every re-posted mouse-moved event is expensive. While hovering, I could get my CPU to spike to 50% (M5 Pro). One solution is to gate the observer callback with a call to `CGEventSource.counterForEventType` and exit early if the counter hasn't incremented: ```swift var lastKeyEventCount = UInt32.max ... let keyEventCount = keyEventTypes.reduce(0) { // .keyUp and .keyDown $0 &+ CGEventSource.counterForEventType(.combinedSessionState, eventType: $1) } guard keyEventCount != lastKeyEventCount else { // Nothing was pressed or released since the last pass so there is nothing to do. return } ``` There is a side-effect though: the counter doesn't increment while a menu _within the hosting app_ is open. In other words, you can't activate the shortcut while a menu in your own app is open. See https://github.com/jamdotdev/KeyboardShortcuts/tree/menu-performance