The more I type, the slower the prediction/speed

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!

1 Like

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.

How to setup to capture a performance profile for Keyman

You’ll need:

  • your phone
  • a computer running Chrome
  • optionally (but usually simpler), a USB cable to connect your phone and the computer

More details and troubleshooting steps for this process are available in the Chrome Developer remote debugging documentation.

  1. On your phone, enable debugging:
  1. Open the Settings app.
  2. Select About phone.
  3. Tap Build number 7 times.
  4. Return to the previous screen to find Developer options.
  5. Scroll down and enable USB debugging.
  1. Connect your phone and computer with the USB cable.
  2. Unlock your phone.
  3. Make sure that the Keyman keyboard is visible on your phone in the context with the performance issue.
  4. On Chrome on the computer, open a new tab and navigate to chrome://inspect
  5. Your phone should show a message asking you to trust the computer for debugging. Go ahead and do that.
  6. Back on the Inspect tab on your computer, you should see a section titled Remote Target, and after a few seconds an entry called WebView in com.tavultesoft.kmapro. There may be two of these – one for the keyboard in the Keyman app, and one for the system keyboard. Select the one that is not marked as “hidden”, and click Inspect.
  7. If all goes well, you should see the Keyman for Android keyboard appear in a new DevTools window on your computer, looking something like this:

How to capture a performance profile

  1. After completing the above steps, click on the Performance tab in DevTools.
  2. Click the record button (:black_circle: icon in the toolbar) (or press Ctrl+E).
  3. On the phone, reproduce the performance issue.
  4. Click Stop on the computer to finish the performance trace.
  5. Click the download icon (image) to save the trace to disk
  6. Finally, send the trace to us in a DM on this forum (you may need to zip it first).

(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’.)

1 Like

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.

1 Like

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.

1 Like

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 :slight_smile:

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!

Note, the two relevant fixes are #5377 and #5352.

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.

1 Like

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.

1 Like

:confetti_ball: :tada: :confetti_ball: :tada: :confetti_ball: :tada:

Thank you too @rowbory and you @katelem for your feedback and patience as we worked through this!

:heart:

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.