-
-
Notifications
You must be signed in to change notification settings - Fork 16
Performance Improvement History
I'll use this Wiki page to record the performance improvements I've been able to make to the config and the keymapper, instead of continuing to fill up the README with new updates.
Performance started out really bad on older hardware, and even modern CPUs would have a core or thread saturated by the keymapper attempting to keep up with rapid typing. And there was a frequent "buffering" effect as key events built up in memory and couldn't come out fast enough.
The buffering can still happen on really old CPUs, if the input is fast enough. But the overall performance has improved drastically during the last couple of months. It's worth noting that most of the CPU usage that happens while typing on a really old dual-core system actually appears to be coming from the editor itself, and the shell. The keymapper will only be a relatively small portion of the total CPU usage.
Using a Python script to estimate the actual equivalent words-per-minute of my "key mashing" testing, it came out to around 225-250 WPM. That's with me literally hitting rolling sequences of keys as fast as I can, and hitting the Space bar frequently to mimic natural word length variation. If you're in the 25-100 WPM typing speed range, the keymapper should currently handle that very well even on most older systems that are still usable in general, and even with the relative complexity of Toshy's config file. If you are using a much simpler "barebones" type of config file, it will have much lower CPU usage than even the best results here.
Measurable improvement in performance again, by removing more resursive lists of conditions and replacing with static regex strings. On a 2007 Core 2 Duo MacBook the maximum CPU usage of the config at high rates of key input was ~10%, while normal typing was around 3%. A 4-core Intel J4125 mini PC now shows ~2%, and a 4c/8t Ryzen 3700u laptop shows a forced maximum of ~2.5%, with normal typing using less than 1%.
Adding to both of the performance updates below, some lists in the config file that are accessed frequently were optimized in a way that once again reduced overall CPU usage while typing. In testing on a multi-core system the CPU usage is usually less than 2%, even while processing keys much faster than most people can type.
Additional performance (reduction in CPU usage) was gained by rearranging the order of evaluation of multi-condition modmap and keymap conditional expressions in the config file. Conditions that were "lighter" like a simple boolean variable check were placed before conditions that are computationally "heavier", like asking the matching function to evaluate a list of context conditions. This optimization procedure had a surprisingly large effect on how much CPU is used during rapid typing (tested by mashing keys as fast as possible). To get these optimizations of the config file, you will need to grab a new zip file and reinstall Toshy.The improvements from this optimization of the config file conditionals are in addition to the performance improvements described in the earlier update below.
Some major performance updates to a core property matching function have significantly reduced the CPU usage of Toshy while typing, especially while typing very fast. This should reduce the incidence of seeing a "delay" in characters appearing while typing, which can happen sometimes when a system is experiencing high CPU usage in general. (You can do something like sudo renice -n -10 $(pgrep xwaykeyz) if you still have an issue with that, and want the keymapper process to have a higher priority when the system is under heavy load.) There was also a sort of fix inside the keymapper recently to keep repeating keys from using up CPU for no particular benefit. Any new install of Toshy, even from an older zip file, will get that when it clones the keymapper from its GitHub repo. Mostly this will be meaningful in gaming situations where one needs to hold down non-modifier keys, which used to cause the keymapper to use an entire core (or thread) for as long as the key was held down.