I hear you. I’ve done some investigation and have a reproduction of the issue.
Here’s my initial writeup of the problem: #5246
We’ll be investigating!
I hear you. I’ve done some investigation and have a reproduction of the issue.
Here’s my initial writeup of the problem: #5246
We’ll be investigating!
Yes, it’s unfortunately fairly crippling for me on Android 8.1 on an item W5504 (P33) with 1GB RAM, 4 Core CPU. Is the best mitigation just not to use lexical models for now, or to keep them small?
We have a patch coming in 14.0.276 which should mitigate this. We intend to publish that version in the next day or so.
Version 14.0.276 is now available. Let us know how you go with it!
There is an improvement in 14.0.276, but the issue persists. After about 8 to 10 lines on my device, it slows down till it starts “hanging” again.
Thank you for the feedback @katelem. That’s a bit of a disappointment, isn’t it?
I wonder if either of you (@katelem or @rowbory) would be willing to attempt to capture a performance profile from your device? This would help us to ensure we are chasing the right performance hotspot from our end. There are a few steps for setup the first time, but it’s not awfully complicated.
You’ll need:
More details and troubleshooting steps for this process are available in the Chrome Developer remote debugging documentation.
- Open the Settings app.
- Select About phone.
- Tap Build number 7 times.
- Return to the previous screen to find Developer options.
- Scroll down and enable USB debugging.
chrome://inspect
(You may want to capture two traces: one with an empty buffer so we can see Keyman performing ‘normally’, and one where keystrokes are ‘hanging’.)
Thanks @rowbury, I’ve reviewed the profile and confirm that the performance hotspot is still in the same place – so the mitigation was not sufficiently effective. We’ll have another go at resolving that.
Thanks. Will try to keep an eye on developments and can test again. The most annoying thing for me is not that prediction lags but that the key presses get slower and slower until you are just watching everything play out in slow motion. I’ve no idea if prediction could run in a different thread or be killed and restarted when a new key is pressed, but that might also help.
The predictions already run in their own thread and are time-bound as well.
In this case, this is a preparation routine that is preparing key event probabilities for the prediction thread – which currently needs to be done in the main thread – and the issue is it is processing the entire document for context when it really doesn’t need to. Resolving that to use a sliding window is going to take a bit of extra effort but we will be wokring on that.
Thanks for the hard work on this. As @katelem mentioned the fact that other key presses don’t appear to respond for increasing time is the most problematic factor and after a few lines makes the keyboard nearly unusable. I notice as I’ve been trying to ‘eat my own dog-food’ for a while before recommending the keyboard to others.
Thanks @rowbory. We are still actively working on this and have another update in the pipeline to go out in the next 14.0 release, either tomorrow or early next week. See #5352.
Many thanks. I’m wondering if there’s anything about the keyboard or lexical model that can hint to the engine how big the sliding window needs to be. I’m thinking the longest word in the lexical model would be a likely limit. Anyway, I mainly came here to say thanks for the hard work and the progress report.
Thank you @rowbory
There’s nothing in the keyboard or model which impacts performance significantly, in vast majority of cases. The sliding window size is fixed currently to 64 characters but that can be adapted in future versions as necessary (at 64 characters, there is no performance issue that we’ve observed on any device).
We’ve just released version 14.0.277 which has significant additional performance improvements for Android, iPhone and iPad, and web. It should be available now or shortly if you check for updates on your device. Please do let us know how it goes!
I know you know it fixes it but I’m delighted - it really makes the keyboard considerably more usable. Thanks so much for all your hard work. Now I just need to wait to see when this can make it into Keyboard App Builder. I haven’t taken the time to figure out how changes from v13 to v14 will impact the integration into KAB, but this is a very major usability improvement which most users will urgently need.
It’s really good to hear the feedback that you are seeing the benefit of the fix. It’s not always 100% clear whether a fix will positively impact all users, particularly when there is a performance issue. So thank you @rowbory for the rapid feedback!
This issue has been resolved! I could type at length without the keyboard slowing down.
Thanks @rowbory for capturing and submitting the profile in time so the Keyman team had the information they needed to work with.
Thanks @Marc and the Keyman team for this significant fix. More grace.
Keyman app is really a lifesaver over here.
Yes, it’s very good. Now I’m just eagerly watching out for an updated KAB so I can rebuild my pan-Nigerian keyboard and reap the benefits. At least I can use the Keyman version for now.