I have one more update just to document things:
The concrete thing where the issues I discussed in this thread occurred was the Click and Drag to 'Scroll & Navigate' feature in Mac Mouse Fix 3 Beta 7. The source code for the app is freely available if anybody wants to try and reproduce this.
My tests consisted of launching the 'Mac Mouse Fix Helper' app via the Xcode debugger, or alternatively by double clicking it in Finder or toggling the 'Enable Mac Mouse Fix' switch in the 'Mac Mouse Fix' app. (If you want to reproduce this, make sure that the 'Mac Mouse Fix Helper' app is properly embedded in the Mac Mouse Fix app. It won't run correctly if it's launched from outside the 'Mac Mouse Fix' bundle).
After launching the 'Mac Mouse Fix Helper' app, I held down the button assigned to the 'Scroll & Navigate' feature, and then wiggled the mouse back and forth at a consistent speed for an extended period of time. Then I looked at the CPU usage in Activity Monitor.
When 'Mac Mouse Fix Helper' was launched by the Xcode debugger, the CPU usage was around 20%, when it was launched another way, the CPU usage was around 40%. A huge difference!
Since the last reply I've done some more testing. My findings were that it seems like certain code runs faster when launched by the Xcode debugger, and other code runs slower.
I did the same tests I did for the "Scroll & Navigate" feature and repeated them for the Click and Drag for "Mission Control & Spaces" feature. Here, things were slightly faster when not launched by the debugger. Wiggling the mouse used around 8% CPU when launched by the debugger, and around 7% when launched normally. As a reminder: the "Scroll & Navigate" feature used around 20% CPU when launched by the debugger and 40% CPU when launched normally. So the performance characteristics were completely different! (And I’ve reproduced this dozens of times on my end)
Now this was interesting to test, because both 'Scroll & Navigate' as well as 'Mission Control & Spaces' use partially the same code to process mouse-moved inputs. So What I did was progressively disable different modules of code from both the 'Scroll & Navigate' input processing chain as well as the 'Mission Control & Spaces' input processing chain, until the were doing the exact same thing and calling the exact same code. I did this to try and analyze which of the modules of the input processing chain cause this weird performance characteristic.
And the result is: It seems like the initial processing module (which both of the 'Mission Control & Spaces' as well as the 'Scroll & Navigate' feature have in common) runs around 50% faster when launched by the Xcode debugger vs when it is launched normally. This module doesn't do much, except receive mouse-moved events from a CGEventTap, dispatch to a queue, and do a few simple operations that should be fast. At this point, the processing chains for the 'Mission Control & Spaces' feature and the 'Scroll & Navigate' feature diverge. The further processing for the 'Mission & Spaces' feature seems to run faster when not launched by the debugger, which seems to balance out initial processing module running 50% slower when not launched by the debugger. Overall, 'Mission Control & Spaces' is slightly faster when not launched by the debugger, which is how it should be. However, for 'Scroll & Navigate', it looks different. All the processing modules after the initial one only seem to exacerbate the slowness of not being not launched by the debugger. To the extent, where the whole processing chain for 'Scroll & Navigate' runs 2x slower when not launched by the debugger.
So it seems that only certain code runs slower when the debugger is not attached. I don't know what code exactly has these weird performance characteristics or why, but I can consistently reproduce this on my end.
Next I tried to find a minimal amount of code that has these weird performance characteristics. I found that when I simply create an event tap that listens to mouse moved events (but does absolutely nothing with them) inside applicationDidFinishLaunching:, then that simple code already runs way faster when app is launched by the debugger vs when it's launched normally. When wiggling the mouse, it was using around 2.5% CPU when launched by the debugger, and around 5% CPU, when launched another way. HOWEVER, when I made a new, empty Xcode project and did the same thing - just set up an eventTap inside applicationDidFinishLaunching: that listens to mouseMoved events - then these weird issues didn’t occur. In the fresh project, wiggling the mouse used around 5% in Activity Monitor in every situation.
So I thought, ‘maybe it’s about the build settings’ so I tried deleting everything from my project except for the code that sets up the eventTap in applicationDidFinishLaunching:. I deleted everything from the project, except the build settings and the event tap. And then the weird performance characteristics went away! It was always using 5% CPU when wiggling the mouse. Just like the fresh project.
I have absolutely no clue what’s going on. But if anybody knows more or wants to try to reproduce this I’d be very grateful.
Sorry for spamming up this thread, I guess I'm always deciding that I will quit investigating now, then I documenting my findings, but then I keep investigating in the end, so this is a bit messy.
