关于一部分weasel的用户卡顿的原因和改进建议

[sanshanjianke]

上报前请检查

• 我遇到的问题没有其他人在 issue 里提到过
• 我的小狼毫版本于 rime/weasel 下载
• 我在使用小狼毫的最新发布版本，或最新发布版本后的 CI 构建

操作系统信息

• OS 详细版本:Windows10操作系统及几个其他的操作系统
• 小狼毫版本: 0.16.0.0版、0.15.0.0版

描述遇到的问题
使用weasel进行输入时，输入和选词均存在较大的延迟。
原因在于系统对CPU功耗优化，使CPU在低强度运行时频率较低。

复现步骤
正常输入时，按键后选词框弹出的速度明显缓慢。
打开任务管理器->性能->CPU。
可以看到，此时查看CPU频率在1ghz以下（在我的电脑上是0.5ghz），使用输入法输入时，CPU频率并没有增加多少，几个存在卡顿的朋友也是如此。
我的笔记本电脑切换到高性能模式（此时CPU稳定在2.4ghz），群友的台式机锁频到2ghz以上，并在任务管理器->详细信息中将WeaselServer.exe的优先级设置成实时。
此时再使用Rime进行输入时，可以看到已经完全没有卡顿的现象出现。
综上所述，我推测部分weasel用户卡顿的原因在于系统对CPU功耗优化。

预期行为
希望weasel加入如下功能：
设置一个选项，如果用户存在上述问题造成weasel卡顿时，可以开启该选项。
开启后，用户可以根据需要设置CPU频率。
当输入文字时，weasel自动将CPU频率提升至用户设置的频率。当用户不再输入文字一定时间后（可以设置为用户自定义），weasel放弃控制CPU频率，使其回复默认。如此可以减少笔记本电脑用户的电池能耗，不必担心干扰续航。
如果该功能确实难以实现，希望weasel可以先将该问题通告一下，方便存在卡顿的用户使用、调整。

用户文件
请于此附上 weasel 用户文件夹下的内容，方便开发者调试问题

截图
如果问题需要，可附上 GIF 图片

其他补充说明
如果有其他补充说明，可以写在这里

[fxliang]

报卡顿的同学，大概应该是对整体窗体做了阴影，在节能模式下，CPU不满足快速响应阴影计算的要求吧。阴影是添头，不要盲上。

[sanshanjianke]

我这里应该和窗体阴影的关系不大，我的系统是刚装的，并且安装时就已经关闭了Windows窗体阴影。

在输入第一个字符时，rime会花费150ms左右的时间创建候选框窗体，后续继续输入计算仍然要100ms左右时间进行响应，应该至少有70ms的时间在做内容方面的运算，应该和窗体关系不大。
之前我测试了一下微软拼音输入法做对比，在使用微软拼音进行输入的时候，在第一下卡顿之后，在持续输入时，微软拼音会让cpu频率保持在1ghz以上。这个CPU频率正巧可以使微软输入法不至于卡顿。
相比较使用rime输入法进行输入时，CPU频率一直在0.5ghz和0.7ghz之间波动，在这个频率进行使用，卡顿的感觉就十分明显了。

并且和输入方案应该也没有关系，我用过一台更老的电脑，2011年的probook6450b，使用的是32nm制程的i5-520m，进行长期的Word编辑工作、视频弹幕编辑和QQ聊天。在测试时没有见到任何卡顿的现象。

[sanshanjianke]

报卡顿的同学，大概应该是对整体窗体做了阴影，在节能模式下，CPU不满足快速响应阴影计算的要求吧。阴影是添头，不要盲上。

刚刚发错了，忘了加回复了.... :-)
应该和阴影无关，我在后面的楼层写了一些图文解释。

[fxliang]

小狼毫没有一次很多，每次只有page_size 个（后端给多少就是多少），要优化的话空间在后端上

候选框出现慢：第一个编码上屏后，候选框延迟 1 秒才出现，后续未见卡顿（某字符所对应的候选过多，例如十万个 v 开头的候选）

关于这个问题，奇怪的是，fcitx5-rime 和 Squirrel 未报告卡顿，是不是客户端内做了限制出词的逻辑，比如一次 query 只出 1000 个词。

如果是的话，希望小狼毫也做一个。因为这可以保证大词库，简拼的正常运行，而且对实际使用没有影响，1000 词需要翻 200 页，根本用不上。

@fxliang

[fxliang]

报卡顿的同学，大概应该是对整体窗体做了阴影，在节能模式下，CPU不满足快速响应阴影计算的要求吧。阴影是添头，不要盲上。

刚刚发错了，忘了加回复了.... :-) 应该和阴影无关，我在后面的楼层写了一些图文解释。

我指的是小狼毫的候选窗口阴影特性；

另外可以试试#1253 提高了进程的优先级，可能有一点点改善

[sanshanjianke]

报卡顿的同学，大概应该是对整体窗体做了阴影，在节能模式下，CPU不满足快速响应阴影计算的要求吧。阴影是添头，不要盲上。

刚刚发错了，忘了加回复了.... :-) 应该和阴影无关，我在后面的楼层写了一些图文解释。

我指的是小狼毫的候选窗口阴影特性；

另外可以试试#1253 提高了进程的优先级，可能有一点点改善

感觉我这个应该没有开窗口阴影特效。


优先级的话，我之前有做过尝试，即便是调整成实时也没有太大的改变。我以前也试着推荐让几个遇见过这个问题的朋友尝试，但都没有明显的改善。
但是将CPU频率拉起来，确实能得到很明显的提升。即便是一些由于本身lua算法设计问题造成的延迟也能得到不小的改善。
所以希望设计一个这样的功能，即便用户可能因为设置或方案设计问题造成卡顿，也能通过拉高CPU频率这样的方法，将问题掩盖掉。

[sstiger1230]

我现在遇到的问题是隔一段时间Windows会整个卡上2、3秒钟，键盘没有反应，鼠标点任何窗口都没有响应。

不知道什么原因。

[Qeynos]

安装了b1aebe8，目前最新的nightly，但出现了卡一下然后后台崩溃的情况，添加的守护进程没有生效，需要手动重启服务才行。

经过这次崩溃后正常运行的时间里，日志里有看到守护进程拉起后台的日志

[fxliang]

安装了b1aebe8，目前最新的nightly，但出现了卡一下然后后台崩溃的情况，添加的守护进程没有生效，需要手动重启服务才行。

经过这次崩溃后正常运行的时间里，日志里有看到守护进程拉起后台的日志

守护不是一崩就拉起，如果连续6次按键消息无响应后拉起

另外卡一下之后，应该会在日志目录里面生成dmp崩溃文件，右击->日志文件夹可以看到

[Qeynos]

安装了b1aebe8，目前最新的nightly，但出现了卡一下然后后台崩溃的情况，添加的守护进程没有生效，需要手动重启服务才行。
经过这次崩溃后正常运行的时间里，日志里有看到守护进程拉起后台的日志

守护不是一崩就拉起，如果连续6次按键消息无响应后拉起

另外卡一下之后，应该会在日志目录里面生成dmp崩溃文件，右击->日志文件夹可以看到

确实有dmp文件，需要发上来吗

[fxliang]

安装了b1aebe8，目前最新的nightly，但出现了卡一下然后后台崩溃的情况，添加的守护进程没有生效，需要手动重启服务才行。
经过这次崩溃后正常运行的时间里，日志里有看到守护进程拉起后台的日志

守护不是一崩就拉起，如果连续6次按键消息无响应后拉起
另外卡一下之后，应该会在日志目录里面生成dmp崩溃文件，右击->日志文件夹可以看到

确实有dmp文件，需要发上来吗

看这个吧，自行消化一部分
#1259

[Qeynos]

安装了b1aebe8，目前最新的nightly，但出现了卡一下然后后台崩溃的情况，添加的守护进程没有生效，需要手动重启服务才行。
经过这次崩溃后正常运行的时间里，日志里有看到守护进程拉起后台的日志

守护不是一崩就拉起，如果连续6次按键消息无响应后拉起
另外卡一下之后，应该会在日志目录里面生成dmp崩溃文件，右击->日志文件夹可以看到

确实有dmp文件，需要发上来吗

看这个吧，自行消化一部分 #1259

消化不了...

[fxliang]

关闭用户词典大概率就不太崩了

[Qeynos]

关闭用户词典大概率就不太崩了

但以往版本不会这么能感知崩溃

[red-co]

+1

[linlin4112]

非常感谢了。
我之前也是这样，一旦开始打长文字，很快就会出现卡顿，在之前带团的时候问题非常严重（就算是CPU此时已经处于高频率也是这样）
看了issue后我改了优先级，现在非常跟手了。
所以其实我觉得核心问题和CPU的频率无关，主要问题还是Weasel的CPU调用有问题，可能是由于什么原因，让系统分配的CPU时间少……

[raawaa]

我长时间运行之后也会变得越来越卡，重启算法服务之后会好一点