Keyboard crash on language switch

[Mokhyy]

Issue description:
Since version 3.9.8, a bug has been introduced causing the keyboard to momentarily freeze whenever the language is switched. (This issue was not present in 3.9.7).

Investigation:
Initially, I suspected it was an issue with importing my settings, but upon closer inspection, I realized the stuttering is related to dictionary loading. It seems that every time the language is switched, the dictionary is removed from memory and reloaded. Switching languages multiple times leads to a full keyboard crash.

Proposed solution:
I believe you should switch the dictionary loading process to an async task to prevent the main thread from blocking and causing these UI freezes.

Technical details:
I tested two scenarios:

1. Without imported dictionary: The keyboard stutters after switching languages multiple times but does not crash (likely due to the English dictionary still being loaded).
2. With imported Persian dictionary: The keyboard triggers an "Application Not Responding" (ANR) error and crashes after only 1 or 2 switches.
   (The Persian dictionary is 12MB. )

---

version: 3.9.8
Device: poco x6 pro
OS: android 15( hyperos 2.0.209)

---

By the way, congratulations! The glide typing engine is working really well. Its startup speed is a bit slow, which I assume is also due to the dictionary loading bottleneck. Fixing the issue mentioned above should resolve this as well.

[LeanBitLab]

Issue description: Since version 3.9.8, a bug has been introduced causing the keyboard to momentarily freeze whenever the language is switched. (This issue was not present in 3.9.7).

Investigation: Initially, I suspected it was an issue with importing my settings, but upon closer inspection, I realized the stuttering is related to dictionary loading. It seems that every time the language is switched, the dictionary is removed from memory and reloaded. Switching languages multiple times leads to a full keyboard crash.

Proposed solution: I believe you should switch the dictionary loading process to an async task to prevent the main thread from blocking and causing these UI freezes.

Technical details: I tested two scenarios:

1. Without imported dictionary: The keyboard stutters after switching languages multiple times but does not crash (likely due to the English dictionary still being loaded).
2. With imported Persian dictionary: The keyboard triggers an "Application Not Responding" (ANR) error and crashes after only 1 or 2 switches.
   (The Persian dictionary is 12MB. )

version: 3.9.8 Device: poco x6 pro OS: android 15( hyperos 2.0.209)

By the way, congratulations! The glide typing engine is working really well. Its startup speed is a bit slow, which I assume is also due to the dictionary loading bottleneck. Fixing the issue mentioned above should resolve this as well.

check latest

[Mokhyy]

I’ve tested the new version, and it’s significantly better than v3.9.8. The UI no longer freezes, and the app doesn’t crash after switching languages once or twice. However, it still hitches in certain scenarios when I switch between Persian and English multiple times.

I think you should investigate which other parts of the keyboard processing can be offloaded to background threads or handled asynchronously.

[LeanBitLab]

can you try another language except persian that might cause the same issue due to its size

[Mokhyy]

"I think that the keyboard lag experienced after switching languages multiple times might be due to the dictionary being unloaded and reloaded upon each language change. Given that Kotlin relies on a Garbage Collector (GC), this frequent cycle of loading/unloading likely causes a significant accumulation of garbage, leading to performance hitches.

I haven't reviewed the source code yet, but is there a mechanism where the dictionary is explicitly cleared from memory and reloaded every time the language is toggled?

If this is the case, here are a few potential optimizations:

1. Memory Lifecycle Management: Instead of clearing the dictionary on every language switch, only release it in onDestroy or onfinish input.
2. Asynchronous/Chunked Loading: Load the dictionary in chunks in the background instead of loading the entire file at once.
3. Grammar-Based Engine: Instead of storing a flat list of every word form, structure the dictionary into two parts: base forms (lemmas) and a grammar engine. Instead of storing 10 variations of a single verb, store only the root (infinitive). The engine can then dynamically generate the inflections on the fly, reducing the search space significantly.

Additionally, it would be worth checking the indexing and search logic to ensure those operations are being performed on a background thread. I think,these parts might be implemented in C++."

[LeanBitLab]

"I think that the keyboard lag experienced after switching languages multiple times might be due to the dictionary being unloaded and reloaded upon each language change. Given that Kotlin relies on a Garbage Collector (GC), this frequent cycle of loading/unloading likely causes a significant accumulation of garbage, leading to performance hitches.

I haven't reviewed the source code yet, but is there a mechanism where the dictionary is explicitly cleared from memory and reloaded every time the language is toggled?

If this is the case, here are a few potential optimizations:

1. Memory Lifecycle Management: Instead of clearing the dictionary on every language switch, only release it in onDestroy or onfinish input.
2. Asynchronous/Chunked Loading: Load the dictionary in chunks in the background instead of loading the entire file at once.
3. Grammar-Based Engine: Instead of storing a flat list of every word form, structure the dictionary into two parts: base forms (lemmas) and a grammar engine. Instead of storing 10 variations of a single verb, store only the root (infinitive). The engine can then dynamically generate the inflections on the fly, reducing the search space significantly.

Additionally, it would be worth checking the indexing and search logic to ensure those operations are being performed on a background thread. I think,these parts might be implemented in C++."

#291 (comment) seems this causing issue

[LeanBitLab]

"I think that the keyboard lag experienced after switching languages multiple times might be due to the dictionary being unloaded and reloaded upon each language change. Given that Kotlin relies on a Garbage Collector (GC), this frequent cycle of loading/unloading likely causes a significant accumulation of garbage, leading to performance hitches.
I haven't reviewed the source code yet, but is there a mechanism where the dictionary is explicitly cleared from memory and reloaded every time the language is toggled?
If this is the case, here are a few potential optimizations:

1. Memory Lifecycle Management: Instead of clearing the dictionary on every language switch, only release it in onDestroy or onfinish input.
2. Asynchronous/Chunked Loading: Load the dictionary in chunks in the background instead of loading the entire file at once.
3. Grammar-Based Engine: Instead of storing a flat list of every word form, structure the dictionary into two parts: base forms (lemmas) and a grammar engine. Instead of storing 10 variations of a single verb, store only the root (infinitive). The engine can then dynamically generate the inflections on the fly, reducing the search space significantly.

Additionally, it would be worth checking the indexing and search logic to ensure those operations are being performed on a background thread. I think,these parts might be implemented in C++."

#291 (comment) seems this causing issue

might not , its actually related to gesture engine

[LeanBitLab]

"I think that the keyboard lag experienced after switching languages multiple times might be due to the dictionary being unloaded and reloaded upon each language change. Given that Kotlin relies on a Garbage Collector (GC), this frequent cycle of loading/unloading likely causes a significant accumulation of garbage, leading to performance hitches.

I haven't reviewed the source code yet, but is there a mechanism where the dictionary is explicitly cleared from memory and reloaded every time the language is toggled?

If this is the case, here are a few potential optimizations:

1. Memory Lifecycle Management: Instead of clearing the dictionary on every language switch, only release it in onDestroy or onfinish input.
2. Asynchronous/Chunked Loading: Load the dictionary in chunks in the background instead of loading the entire file at once.
3. Grammar-Based Engine: Instead of storing a flat list of every word form, structure the dictionary into two parts: base forms (lemmas) and a grammar engine. Instead of storing 10 variations of a single verb, store only the root (infinitive). The engine can then dynamically generate the inflections on the fly, reducing the search space significantly.

Additionally, it would be worth checking the indexing and search logic to ensure those operations are being performed on a background thread. I think,these parts might be implemented in C++."

No, the dictionaries are not unconditionally unloaded and reloaded upon each language change. it implements a dictionary re-use mechanism in DictionaryFacilitatorImpl.kt to optimize resources.
The method getNewDictGroupsAndDictsToCleanup compares the list of newly requested locales with the currently loaded locales:

• Locales that stay active: The facilitator reuses the loaded dictionary instances (both the main dictionary and any sub-dictionaries
like user history, contacts, or user dictionary) without closing or reloading them.
• Locales that are no longer needed: Their dictionary types remain in the cleanup list

[LeanBitLab]

The performance hitches/battery drains previously seen during language/layout changes were due to concurrency bugs (such as the thread storm in Suggest.kt spawning dozens of concurrent threads that competed for CPU and JNI locks), not Kotlin/JVM garbage collection overhead.

[LeanBitLab]

https://github.com/LeanBitLab/LeanType/releases#release-v4.0.0-beta1