改善拼音输入速度
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
),只要重新编译一份非常小的拼写映射文件。