改善拼音输入速度
Opened this issue · 6 comments
Is your feature request related to a problem? Please describe.
在Trime中，如果词库较大，并且使用简拼规则，会出现输入特定内容时反应速度极慢的问题。
我猜测是简拼尝试了大量无效自造词的组合，造成了资源浪费。
Describe the solution you'd like
1 添加参数，限制script translator的自造词组合时，合成词条所使用的原词条的长度。从而减少运算量和出现没有意义的硬造的候选词。 就是说，假设极端情况词库只有单字啊，关闭自造词，限制设置3，输入aaaaaaa，候选词最长只有啊啊啊，不会造更长，后边的内容分段完成。（变坏的情况也仅此而已）
2 另外rime能否做长词预测？比如词库有梅塞德斯奔驰，当输入msdsb时就预测到这个词条
不能靠猜。
得靠添加索引。
aaaaaaa 是沒問題的，運算量不大。
現在就有限制。
問題在於簡拼。
限制不住的是，簡拼對應的音節數是10^2量級，詞典是按音節索引的，輸入簡拼需要把每個不同音節查一次，在每個音節的前幾名中比出簡拼對應的前幾名。這部分目前是沒有索引的，運算量是在10^2個音節之間排序，而不在於取幾名。
禁用簡拼就可以減少這部分運算。
之後再手動添加簡拼索引也是可以的。另設一個script_translator只用來輸入簡拼 。缺點是不能在一句話裏混用全拼簡拼。
之後再手動添加簡拼索引也是可以的。另設一個
script_translator只用來輸入簡拼 。缺點是不能在一句話裏混用全拼簡拼。
如果另设一个translator, 还需要把当前词库文件复制一份,来部署出不同索引的bin文件,对嘛?
之後再手動添加簡拼索引也是可以的。
啊不对, 手动添加索引是怎么做?
我理解的是没有索引值是说abbrev没有索引,而xform有索引,是嘛?所以另一个translator用xform代替abbrev?
那这样的话如果用derive,写在同一个翻译器里而不是两个,也就有索引了索引可以产生提速效果.但是会出现简拼优先级也比较高的问题?
究極的解法是在詞典裏添加簡拼的索引，比如給出 s 對應的前10個候選字。現在不支持啊。
分出一個translator做純簡拼，如果繼續與全拼共用詞典，大頭還在，減少的運算量是全拼、簡拼混合的那部分搜索路徑，大頭還在，我又合計了一下可能改善不大。
分出一個translator做純簡拼，如果繼續與全拼共用詞典，大頭還在，減少的運算量是全拼、簡拼混合的那部分搜索路徑，大頭還在，我又合計了一下可能改善不大
我对librime的理解还是非常有限。
在简拼全拼共用词库的前提下，是否有机会做这样一种translator呢：
- 1个词库文件生成全拼、简拼两种索引
- 用户输入后，根据索引和拼运规则，得到对应的纯简拼编码
- 使用纯简拼查询得到初级候选，根据用户输入的原编码对初级候选进行匹配，得到准确的候选
编码是编译词典时算好的。也就是说拼写运算规则是运用在编译期。
加简拼索引等于是用空间换时间，把简拼对应全拼下的候选合并排序的过程也在编译期做了。
简拼索引应该不是独立编制的，因为还要支持简拼与全拼混合的查询。
至今没做这个索引，是为了灵活性优先：
改动拼写运算规则不需要重新编译固态词典（*.table.bin），这是一个费时的操作；
同时，不使用简拼索引有利于固态词典的共用——比如双拼输入方案，有不同的拼写运算规则包括简拼的设置，然而在目前的逻辑之下可以直接借用拼音方案的固态词典（*.table.bin），只要重新编译一份非常小的拼写映射文件。