revar

Results 10 comments of revar

的确很慢,我还以为是mac的锅,换了软件后才知道了是软件的问题

> > 的确很慢,我还以为是mac的锅,换了软件后才知道了是软件的问题 > > 二楼的老哥有什么软件可以推荐下吗? 目前在试用Tuxera NTFS,速度能到70MB/s左右,虽然不到我的硬盘的正常速度(180MB/s),但好歹能凑活用了

哇非常感谢,我会结合你的反馈进行修正

A temporary solution is to set the test version bar at the bottom, although it will still run to the top when it is not full screen.😢 ![image](https://github.com/user-attachments/assets/225fbf74-17c4-49e0-8a10-615da5ef8e5f)

> A temporary solution is to set the test version bar at the bottom, although it will still run to the top when it is not full screen.😢 ![image](https://private-user-images.githubusercontent.com/29756950/352878587-225fbf74-17c4-49e0-8a10-615da5ef8e5f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjIyMTAzMDUsIm5iZiI6MTcyMjIxMDAwNSwicGF0aCI6Ii8yOTc1Njk1MC8zNTI4Nzg1ODctMjI1ZmJmNzQtMTdjNC00OWUwLThhMTAtNjE1ZGE1ZWY4ZTVmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzI4VDIzNDAwNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTMyMzg1ZTk2YjQ2ZTIyMDI1NjNjMzA5MGEwZTVlN2MwMzFjZDU4ZmJiYmFkZjJhYjVkNjFiZTMwYTA0NmYxY2UmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.6m9tDtQ_YQc9ygPsqj8omcrgDnrlgJtCFM-iD_ESOog) Then...

测试可行,我这边断电后就锁定了

经过process monitor追踪发现是他会实时的进行数据库文件的更新,但是每次只有不到100字节的写入却造成了如此巨量的开销. 我刚才使用gemini cli尝试修复了一下,加了点防抖, 但是没有起到想要的效果. 17:04:04.4281158 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 6,676, Length: 72 17:04:05.0849222 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 6,748, Length: 72 17:04:05.9569996 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log...

> 简单看了一下,每次 commit 会造成 leveldb 的 WAL 写入,至于为什么会有这么严重的写放大就不太清楚了(也可能是 taskmgr 统计口径的问题)。解决方案似乎只能是 rime 侧做 batch。 目前观察到的情况是 跟源代码中的逻辑一样 只有开启新的输入时 他会对log文件进行上一次输入的filewrite, 然后问题是我在持续键入未未上屏的情况下, taskmgr的io写入数据一直在暴涨. 此时在process manager中是没有磁盘文件写入的. 就有点不确定是否有真的io写入了. 如果是真的每次输入三个字就会造成ssd硬盘的1MB写入开销多少还是有点遭不住. 接下来我会继续看看taskmgr的统计标准, 和看看能否把这种放大解决一下

> > 简单看了一下,每次 commit 会造成 leveldb 的 WAL 写入,至于为什么会有这么严重的写放大就不太清楚了(也可能是 taskmgr 统计口径的问题)。解决方案似乎只能是 rime 侧做 batch。 > > 目前观察到的情况是 跟源代码中的逻辑一样 只有开启新的输入时 他会对log文件进行上一次输入的filewrite, 然后问题是我在持续键入未未上屏的情况下, taskmgr的io写入数据一直在暴涨. 此时在process manager中是没有磁盘文件写入的. 就有点不确定是否有真的io写入了. 如果是真的每次输入三个字就会造成ssd硬盘的1MB写入开销多少还是有点遭不住. > > 接下来我会继续看看taskmgr的统计标准, 和看看能否把这种放大解决一下...

好吧,既然这样的话那就先不管io的问题了. 我现在发现让输入法卡顿的原因是chrome导致的,当使用chrome打开过多个视频网站后,就会出现奇卡无比的现象.此时就算关闭所有的标签页也是仍然卡顿.重启weaselServer也无效.只能通过关闭chrome浏览器来解决. 我捕捉到了这一现象,不是很清楚怎么回事,但是卡顿的时候会在process explorer中显示chrome正在等待写资源wait:wrresource与running 此时切换到其他输入法恢复正常. stack为: ntoskrnl.exe!KeSynchronizeExecution+0x5b66 ntoskrnl.exe!KeWaitForSingleObject+0x1460 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeWaitForSingleObject+0x233 ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd ntoskrnl.exe!KeWaitForSingleObject+0x3a29 ntoskrnl.exe!KeWaitForSingleObject+0x1787 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeWaitForMultipleObjects+0x2be ntoskrnl.exe!ObWaitForMultipleObjects+0x2f0 win32kfull.sys!NtHWCursorUpdatePointer+0x6b2 0x0000000000000000 win32kbase.sys+0x915b1 win32kfull.sys!NtUserMsgWaitForMultipleObjectsEx+0x3fe 0x0000000000000000 win32u.dll!NtUserMsgWaitForMultipleObjectsEx+0x14 USER32.dll!MsgWaitForMultipleObjectsEx+0x9e chrome.dll!IsSandboxedProcess+0xd0e293 chrome.dll!IsSandboxedProcess+0xd0def2 chrome.dll+0x6dced chrome.dll!IsSandboxedProcess+0x1784929 chrome.dll+0xc62c4e chrome.dll!ChromeMain+0x42f26 chrome.dll!ChromeMain+0x42b7c...