[Perf] Reduce the amount of time the EVENT_OBJECT_LOCATIONCHANGE hook is enabled
TheMrJukes opened this issue · comments
Summary of the new feature/enhancement
Simply moving the cursor is enough to generate an EVENT_OBJECT_LOCATIONCHANGE.
Last I checked, PT registers for EVENT_MIN/EVENT_MAX in SetWinEventHook.
You'll notice that moving the cursor around the screen quickly is enough to spike PT CPU usage to 3-5% depending on the PC.
The idea is to reduce the amount of time PT is spent registered to receive EVENT_OBJECT_LOCATIONCHANGE and other events it does not need to process.
Proposed technical implementation details (optional)
TheMrJukes/PowerToys@master...TheMrJukes:user/bretan/pt-optimize
This is not completely ready to ship but I haven't had time recently to fully finish it up.
The idea is that we ask each powertoy exactly which events it needs for SetWinEventHook.
This way we only register for the required events.
It is more efficient to have 30 hooks registered for the specific events necessary than it is to have 1 hook registered for a larger range of events. The overhead of having a bunch of hooks enabled to the kernel is minimal.
It also provides a callback to allow the powertoy a way to change which events it requires. This lets FZ only request EVENT_OBJECT_LOCATIONCHANGE while a drag is in progress.
Thanks @TheMrJukes this is a great improvement!
When you have time, can you give us your feedback on #961?
Thank you.
putting in 20.03, we may be able to pull this in sooner per @enricogior
I've rebased the branch to the current master (cherry-picked line by line manually, because every commit had a conflict almost in every file) and considered the proposed idea. It looks like we need to at least partially implement #961 for it to work, so I'm reestimating this a bit. What we need to do:
- implement the ability to un/subscribe to a certain event dynamically for a certain toy
- fix the way
modules()
/powertoys_events()
work. currently it's trivial to create a race condition from using them (and we may already have one) - settle on the design of #961, so we don't do any incompatible features
To finish #961:
- change the way we launch toys, so the events are always served from a particular thread
- change the existing PT to accommodate with the updated event system (we can't have two versions of event system at the same time due to interface change and the way hooks work)
I've just finished drafting the design, but need to test some concepts, though it seems like a viable task for 0.16 nevertheless.
moving this toward 0.18 and 0.19 to wrap up. will be done with setting simplification work
The fix is now available in 0.18 https://github.com/microsoft/PowerToys/releases