WeaselDeployer 大约支持多大规模的部署？

[ChihSee-Hsie]

如题，我尝试着部署大约 60 MB 的词典文件，并将其分成六份，每份大约 10 MB。在部署时我发现最多可以将其中五份的内容部署完成，但再增加就会卡死。打开任务管理器，发现 WeaselDeployer 在此时的内存占用快速增长，到大约 1,200,000 KB 时程序退出运行。然而如果部署的词典大小在 50 MB 左右，WeaselDeployer 占用的内存最多可以达到 1,700,000 KB，仍然完成部署。我考虑 WeaselDeployer 可能有内存限制，特此来询问。如果能有解答，我在这里预先表示感激。

我的系统配置是 Windows 11 22H2 build 22621.1413，RAM 容量 16 GB。此至，祝安！

[ASC8384]

80MB的词典文件，fxliang的最新版本，32GB内存无法部署。
日志里一直有：

a work thread is already running

[Techince]

80MB的词典文件，fxliang的最新版本，32GB内存无法部署。 日志里一直有：

a work thread is already running

可以试试64位版本，如果还存在这个问题，估计就是对词典大小有限制。

[ASC8384]

80MB的词典文件，fxliang的最新版本，32GB内存无法部署。 日志里一直有：

a work thread is already running

可以试试64位版本，如果还存在这个问题，估计就是对词典大小有限制。

发现把use_preset_vocabulary设置成 false 可以部署，但是设置成 true还是不行。

版本是fxliang最近的 PR，里面没有 64 位版本。看 @Techince 您 release 了一个 64 位的版本，但 commit 似乎与现在的差距过大，不知道该如何选择了。

[Techince]

不知道该如何选择了。

我的本地代码基本上跟着Fxliang做的，由于64位与32位不兼容的地方比较多，自动同步会有较多的冲突，网上的源码只增加一些个人添加的代码。Release包是本地编译上传的。

[ASC8384]

不知道该如何选择了。

我的本地代码基本上跟着Fxliang做的，由于64位与32位不兼容的地方比较多，自动同步会有较多的冲突，网上的源码只增加一些个人添加的代码。Release包是本地编译上传的。

也就是说，action里的资源包并非release的版本？

不知道您是否打算提PR:smile:

[Techince]

不知道该如何选择了。

我的本地代码基本上跟着Fxliang做的，由于64位与32位不兼容的地方比较多，自动同步会有较多的冲突，网上的源码只增加一些个人添加的代码。Release包是本地编译上传的。

也就是说，action里的资源包并非release的版本？

不知道您是否打算提PR😄

PR会有比较多的冲突，对于公共部分，我修改的代码会通过QQ告知fxliang的。目前官方还没计划升级到64位。

[fxliang]

rimedeployer_win.zip

提供个玩具，不负责任，哈哈

[ASC8384]

rimedeployer_win.zip

提供个玩具，不负责任，哈哈

请问这个是不是会把default.custom.yaml重置了呀

[fxliang]

rimedeployer_win.zip
提供个玩具，不负责任，哈哈

请问这个是不是会把default.custom.yaml重置了呀

这个目标是外部部署，只看词典产出就好

[ASC8384]

rimedeployer_win.zip
提供个玩具，不负责任，哈哈

请问这个是不是会把default.custom.yaml重置了呀

这个目标是外部部署，只看词典产出就好

可以使用，非常感谢

[ChihSee-Hsie]

rimedeployer_win.zip
提供个玩具，不负责任，哈哈

请问这个是不是会把default.custom.yaml重置了呀

这个目标是外部部署，只看词典产出就好

感谢提供这样一个工具。在实际使用中，x64 的 deployer 编译出了 prism、table、reverse 三个文件，但复制到 build 文件夹后，开启对应方案时会自动重新编译，结果程序仍然卡死，而三个词典文件中 prism 被删除了（应该是意图重新编译 prism，但不能成功的结果）。

[fxliang]

rimedeployer_win.zip
之前随手整的没考虑完整，这个如果user目录下有default.custom.yaml的话是不会覆写的，将小狼毫的共享数据复制到shared/下，用户目录的内容放user目录下，再部署看看，我试了一下没有问题了

主要原因是因为部署产出有时间戳信息，如果两边的状态不一样，就会触发重新部署。