Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve performance by reducing ctypes calls #497

Closed
wants to merge 1 commit into from
Closed

Improve performance by reducing ctypes calls #497

wants to merge 1 commit into from

Conversation

BA-24
Copy link

@BA-24 BA-24 commented Sep 5, 2022

From my testing (albeit with a quite heavily modified version of this script), this provides a roughly 30x performance boost with measurements taken from the first line of _modifier_state to the line after the layout_data assignment in __call__ for the unmodified version and from the first line of __call__ to the line after the layout_data assignment in __call__.

The test was conducting by pressing 4 regular keys (asdf), 4 shift keys ("!#¤), 2 more shift keys (() open and close parentheses) and then 2 ctrl+alt keys ([] open and close brackets). After this, I made a sum of all the measured times between the previously mentioned lines and compared those sums with each other.

From my research, there shouldn't be any problem with some keyboards having different shift/ctrl/alt keys since the vkCodes for these should be the same across all keyboard according this documentation: https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes

IMPORTANT NOTE: This would also require a change to Listener._event_to_key in keyboard/_win32.py since it as of now does not pass "special keys" to KeyTranslator at all, however, I think that the KeyTranslator class should be the one to deal with those as well (especially since it already has access to the win32_vks.py module)

As a final note I would just like to say that I've enjoyed sifting through this project to extract the parts needed for my own and I want to thank everyone that has contributed to it

From my testing (albeit with a quite heavily modified version of this script), this provides a roughly 30x performance boost with measurements taken from the first line of ``_modifier_state`` to the line after the ``layout_data`` assignment in ``__call__`` for the unmodified version and from the first line of ``__call__`` to the line after the ``layout_data`` assignment in ``__call__``.

The test was conducting by pressing 4 regular keys (asdf), 4 shift keys ("!#¤), 2 more shift keys (() open and close parentheses) and then 2 ctrl+alt keys ([] open and close brackets). After this, I made a sum of all the measured times between the previously mentioned lines and compared those sums with each other.

From my research, there shouldn't be any problem with some keyboards having different shift/ctrl/alt keys since the vkCodes for these should be the same across all keyboard according this documentation: https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes

IMPORTANT NOTE: This would also require a change to ``Listener._event_to_key`` in ``keyboard/_win32.py`` since it as of now does not pass "special keys" to ``KeyTranslator`` at all, however, I think that the ``KeyTranslator`` class should be the one to deal with those as well (especially since it already has access to the ``win32_vks.py`` module)

As a final note I would just like to say that I've enjoyed sifting through this project to extract the parts needed for my own and I want to thank everyone that has contributed to it
@moses-palmer
Copy link
Owner

Thank you very much for your contribution, and also your kind words!

While a 30x speedup is a great thing to achieve, I am not certain or is worth it in this case. The calls to GetAsyncKeyState are there to ensure that pynput has the same view of the modifier state as the kernel. If we maintain an internal view, I fear that it may diverge.

Have you noticed any performance issues in the code touched by this PR?

@BA-24
Copy link
Author

BA-24 commented Sep 7, 2022

Hey, sorry for the late reply. I have not noticed any performance issues with that part specifically, however, I have had a similar issue to the one discussed here, however, I had the same issue using the Keyboard module so I wrote my own code (although a lot more simplistic and less feature-rich) to catch keyboard events and I've had no issues with it.

When writing my code, I decided to have it call a separate threaded function doing the actual handling/parsing of the input and then have the hook function return as quickly as possible as to reduce the latency to the rest of the system as much as possible.

That being said, I boiled down all the code to its bare minimum so it's hard to tell what made the difference.

If you want to check out my code here's a link to the page: https://github.com/antudic/QuicKCo
It's specifically in the driver folder with the _listener.py program being responsible for inserting and removing the hooks and then I stole part of your KeyTranslator in win32.py as well, I hope you don't mind

Edit: Just wanted to mention that I am still quite new to using GitHub, I had no intention of closing this by "deleting the head repository" and I have no idea what consequences that will actually have.

@BA-24 BA-24 closed this by deleting the head repository Sep 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants