win11使用该方案，打字会卡顿

[dykwok]

trafficstars

平台： win11 weasel： 0.15.0(nightly)

使用该方案，会有卡顿。在macos上使用同样的配置，无卡顿，问题还未定位（todo)

[HowcanoeWang]

如果词库过多，在循环遍历添加辅助码的时候可能存在性能问题。当然也有可能是nightly版本修改了什么逻辑导致的

[dykwok]

如果词库过多，在循环遍历添加辅助码的时候可能存在性能问题。当然也有可能是nightly版本修改了什么逻辑导致的

对，确实很多。在打log看一下。但按理说我win11的这个电脑比mac的那台要好。没有想到差这么多。

[dykwok]

应该就是词库过大。13w条，换成8k条。没有这个问题了。

8k条的，稍后提个PR。

[jiuxuanzhi]

@dykwok @HowcanoeWang 我发现使用了这个插件后，在Windows上每打开一个新的程序，在该程序中输入文字就会导致小狼毫的内存增加，特别是辅助码文件越大的话，增加的内存就越多，这样输入法就会变得卡顿。但我发现将filter中aux_code变量不挂载到env上而是挂载到AuxFilter上能有效减少增加的内存。

我使用没有修改的代码测试的一个虎码的辅助码（99142行，731KB），在使用默认的代码在越8个程序中进入文字输入，小狼毫的内存可以涨到112M，同样的情况下，将aux_code变量挂载到AuxFilter上内存基本上维持在60M左右。 代码修改示例：

-- env.aux_code = AuxFilter.readAuxTxt(env.name_space)
AuxFilter.aux_code = AuxFilter.readAuxTxt(env.name_space)

当然，还有使用aux_code 的地方也要做修改。

遗憾的是，我自己的体验下来是，小狼毫的内存占用上到40M以上就会有延迟感了，上到60M以上就会有明显的卡顿了。

[HowcanoeWang]

@xiaoyixiao369 windows好像有个功能，记住不同程序用不同的输入法，把那个功能关了看看呢？

[HowcanoeWang]

主要考虑到需要排序，就得吧输入法的候选全部遍历一遍，如果词库非常多，遍历起来就时间很长会很卡

或许可以优化的点，如果当前词库候选超过某个值，则添加辅码仅在输入 ; 符号后触发，这样应该只会在输入那个符号卡一下，而不是会影响全程的打字体验

[jiuxuanzhi]

@xiaoyixiao369 windows好像有个功能，记住不同程序用不同的输入法，把那个功能关了看看呢？

你说的是app_options配置项吗，这个我都没有开的。对了，我设置的候选项个数是7。

[HowcanoeWang]

你说的是app_options配置项吗，这个我都没有开的。对了，我设置的候选项个数是7。

[jiuxuanzhi]

你说的是app_options配置项吗，这个我都没有开的。对了，我设置的候选项个数是7。

是关闭的，跟你的一样。

[jiuxuanzhi]

看到魔然也加了一种双拼+辅助码的方案，看作者说开单字辅助码也有性能问题。https://github.com/ksqsf/rime-moran/releases/tag/1.9

[dykwok]

我换补码词库，8000个左右，速度还可以接受。就是weasel 经常一些程序不可用，没法接受。 速度这个还有个奇怪的是，同样的算法，在不同平台表现不一样。MacOS上13w的词库速度是一点也没有影响。

[HowcanoeWang]

我换补码词库，8000个左右，速度还可以接受。就是weasel 经常一些程序不可用，没法接受。 速度这个还有个奇怪的是，同样的算法，在不同平台表现不一样。MacOS上13w的词库速度是一点也没有影响。

@xiaoyixiao369 我linux上的词库也很多，也可能是电脑性能太好，也一点都不卡顿。

目前看下来，猜测有可能是weasel的rua插件实现有性能问题

[HowcanoeWang]

@xiaoyixiao369 能否把那个9w多行的虎码辅助码分享一下供测试？我感觉卡顿和词库没关系，而是和辅码库的大小有关系

[jiuxuanzhi]

@HowcanoeWang https://github.com/xiaoyixiao369/Rime-Patch-Share/blob/main/lua/huma.txt 可供测试使用。

感觉有个可优化的点： yield(cand)可以换成coroutine.yield(cand)

[jiuxuanzhi]

不知道会不会跟小狼毫本身有关系了，这两天更新了小狼毫夜间版，我4W多行的辅助码表内存可以维持在60多M上下。在新开的软件中输入，内存有所增加，但没有之前那么夸张了。

另外我还优化了一个点，就是使用辅助码筛选后，只筛选出符合用户输入的辅助码的候选项，修改如下代码所示：

        -- 過濾輔助碼
        if #auxStr > 0 and fullAuxCodes and (cand.type == 'user_phrase' or cand.type == 'phrase') and
            AuxFilter.match(fullAuxCodes, auxStr) then
            coroutine.yield(cand)
        else
            local trigger_key_pos = string.find(inputCode, env.trigger_key) -- 找到 "/" 的位置，我的辅助码触发键换成了/
            if trigger_key_pos then -- 确保找到了 "/"
                -- 用户输入了辅助码，确保当用户只输入了一个/时仍然保持单字的辅助码，当/后面有内容时仅仅过滤能匹配上/后面内容的单字或词语
                local content_after_trigger_key = string.sub(inputCode, trigger_key_pos + 1) -- 获取 "/" 后面的内容
                local length_after_trigger_key = string.len(content_after_trigger_key) -- 计算内容的长度
                if length_after_trigger_key <= 0 then
                    table.insert(insertLater, cand)
                end
            else
                -- 用户没有输入辅助码，单字加上辅助码提示
                table.insert(insertLater, cand)
            end
        end

[fxliang]

一些建议供参考，用db而不是读入内存，减少有些代码的循环嵌套，删减非必要的遍历

不知道会不会跟小狼毫本身有关系了

前端不处理算法部分，只是转手传递数据。 内存申请和析构是有开销的，在不同操作系统下有不同的内存调度机制，同时和librime-lua / lua的调度机制也会关联。

[keai336]

如果没有那个引导符,可以直接不处理直接照原样yield然后退出吧

[HowcanoeWang]

如果没有那个引导符,可以直接不处理直接照原样yield然后退出吧

目前确实是准备这么修改的，没有引导符就不启用后续排序，看看效果

[keai336]

应该就是传入的env的问题 https://yourlast.notion.site/window-fada2495d38b4ce6a8f2973e32d4b7d0?pvs=4

[EtaoinWu]

当前逻辑 在没有给定辅助码的时候需要走遍整个词库 input:iter()、加上提示、扔到 insertLater 里，然后再从 insertLater 里逐一 yield 出来。实际上如果已知 auxStr == '' 那么我们可以跳过 insertLater 这一个缓存，直接 yield，能获得较大性能提升，至少本地测试（雾凇，自然码双拼，自然码辅助）不卡了。

[HowcanoeWang]

不知道会不会跟小狼毫本身有关系了，这两天更新了小狼毫夜间版，我4W多行的辅助码表内存可以维持在60多M上下。在新开的软件中输入，内存有所增加，但没有之前那么夸张了。

另外我还优化了一个点，就是使用辅助码筛选后，只筛选出符合用户输入的辅助码的候选项，修改如下代码所示：

        -- 過濾輔助碼
        if #auxStr > 0 and fullAuxCodes and (cand.type == 'user_phrase' or cand.type == 'phrase') and
            AuxFilter.match(fullAuxCodes, auxStr) then
            coroutine.yield(cand)
        else
            local trigger_key_pos = string.find(inputCode, env.trigger_key) -- 找到 "/" 的位置，我的辅助码触发键换成了/
            if trigger_key_pos then -- 确保找到了 "/"
                -- 用户输入了辅助码，确保当用户只输入了一个/时仍然保持单字的辅助码，当/后面有内容时仅仅过滤能匹配上/后面内容的单字或词语
                local content_after_trigger_key = string.sub(inputCode, trigger_key_pos + 1) -- 获取 "/" 后面的内容
                local length_after_trigger_key = string.len(content_after_trigger_key) -- 计算内容的长度
                if length_after_trigger_key <= 0 then
                    table.insert(insertLater, cand)
                end
            else
                -- 用户没有输入辅助码，单字加上辅助码提示
                table.insert(insertLater, cand)
            end
        end

刚刚的更新直接把insertLater优化了，候选不符合辅助码则直接不出现在选单里，不用再遍历所有的候选项，应该会进一步优化性能

[HowcanoeWang]

感谢各位的献计献策，刚刚综合大家的建议更新了候选逻辑，主要更新如下：

• 如果输入字符串中没有辅助码引导符 -> 直接 yield 所有候选项
• 如果输入字符串中有辅助码引导符:
  • 还没有输入辅助码 (只有引导符) -> 根据用户配置，给候选项添加上辅助码提示
  • 输入了辅助码 -> yield 所有符合的候选项，不符合的直接不出现 (直接抛弃 insertLater 表的添加元素与后续补回候选列表中，提升性能)

欢迎大家测试与进一步反馈！

[EtaoinWu]

当前方案在没有辅助码时不会显示提示（而 fe8b3cf 则在没有辅助码时仍然会显示），这个是否可以由一个选项设定来开关呢

[HowcanoeWang]

当前方案在没有辅助码时不会显示提示（而 fe8b3cf 则在没有辅助码时仍然会显示），这个是否可以由一个选项设定来开关呢

我这么改是处于性能考虑，打字过程中候选项一直会改变，这期间轮询添加辅助码似乎意义不大？ 等输入的内容确定了，按辅助码引导键最后只要给所有候选项添加一次辅助码即可

[dykwok]

感谢各位的献计献策，刚刚综合大家的建议更新了候选逻辑，主要更新如下：

• 如果输入字符串中没有辅助码引导符 -> 直接 yield 所有候选项

• 如果输入字符串中有辅助码引导符:

  • 还没有输入辅助码 (只有引导符) -> 根据用户配置，给候选项添加上辅助码提示
  • 输入了辅助码 -> yield 所有符合的候选项，不符合的直接不出现 (直接抛弃 insertLater 表的添加元素与后续补回候选列表中，提升性能)

欢迎大家测试与进一步反馈！

好，非常好，用了半天，控制在了30MB以内。