[Bug] 模组管理页面在3.10版本之后加载异常地慢

[ZZZank]

问题描述 | Bug Description

1. 随便安装一个mod数量不太少的整合包，我测试用的是大约160mod的HighAltitudeAlchemy
2. 分别用HMCL 3.9.2（没有这个问题）, 3.10.1（复现这个问题的最早稳定版）, 3.11.0.325（最新快照）打开这个整合包的模组管理页面，测量加载时间
3. 可以得到：

版本	加载开始时间	加载结束时间	用时
3.9.2	2s	5s	3s
3.10.1	15s	25s	10s
3.11.0.325	35s	45s	10s

测试过程的录屏：

hmcl-mod-management.mp4

启动器崩溃报告 / 启动器日志文件 | Launcher Crash Report / Launcher Log File

3.11.0.325.log.zip
3.10.1.log.zip
3.9.2.log.zip

[3gf8jv4dv]

诡异，可惜没能复现。

注意到你用了火绒。如果临时关闭火绒的文件实时监控功能，3.10 及以上的 HMCL 还会这样么？

[TheWhiteDog9487]

我这里也有这个问题，但没这么恶劣
3.9.2版本，Mod列表加载完成耗时1~1.5秒
3.10.2版本耗时3秒
退出火绒也测试了，对性能没有产生影响

mods.txt
PS G:\Minecraft.minecraft\mods> Get-ChildItem | Out-String -Stream | Out-File -LiteralPath "C:\Users\TheWhiteDog9487\Desktop\mods.txt" -Encoding utf8

[ZZZank]

如果临时关闭火绒的文件实时监控功能，3.10 及以上的 HMCL 还会这样么？

会，我关闭“文件实时监控”之后又重新试了试3.10之后的两个版本，依然是10秒左右完成加载

[3gf8jv4dv]

@TheWhiteDog9487 @ZZZank

我这边试了下，确实 3.10 比 3.9 慢一点 (我这边是慢 1 秒左右)。但慢 10 秒着实离谱。😱

只能排除法挨个试了…… 3.9 和 3.10 之间有近百个 commit：v3.9.1...v3.10.1

[LiuJiewenTT]

我没有火绒，我是360 Total Security（360国际版），明显比3.9慢好多

[3gf8jv4dv]

好消息！我找到了导致问题的 commit&PR：f10c842 (GHA 构建)

• 使用 kala-compress 读取模组元数据 #5146

这个 commit 的前一个 commit：74d379a (GHA 构建)。

需要测试的，可以分别下载这两个构建。

CC @ZZZank @TheWhiteDog9487 @LiuJiewenTT
CC @Glavo @burningtnt @zkitefly

Edit: 链接搞错了，重新编辑了下。

[TheWhiteDog9487]

好消息！我找到了导致问题的 commit&PR：f10c842 (GHA 构建)

* [使用 kala-compress 读取模组元数据 #5146](https://github.com/HMCL-dev/HMCL/pull/5146)

这个 commit 的前一个 commit：74d379a (GHA 构建)。

需要测试的，可以分别下载这两个构建。

CC @ZZZank @TheWhiteDog9487 @LiuJiewenTT CC @Glavo @burningtnt @zkitefly

Edit: 链接搞错了，重新编辑了下。

确实是这个commit的问题，这两个action构建在这个问题上的性能存在显著差异
感谢你帮忙找，辛苦啦

[ZZZank]

我用profiler看了看各个部分的耗时，可以确定kala compress在整个过程中占用了90%以上的总时间：

顺便注意：现在的profiler对虚拟线程的支持似乎非常接近于没有，在profile的时候最好使用Java17而不是Java21

[Glavo]

commons-compress 的原始实现似乎在读取 ZIP 头的时候没有做缓冲，几个字节几个字节读的，导致性能很差劲。有空的话我给 kala-compress 做一下优化。

[ZZZank]

按照现在的最新commit（ 9696446 ）来看，这个问题还没有修好。在最新的commit下加载时间从10秒减低到了大约7秒，但是还是仍然不及原来的3秒：

2026-03-25.213250.mp4

[burningtnt]

重新打开该 Issue 以继续跟踪该问题。既然无脑并发不可取，我们应当继续寻找方案来提升模组加载的性能