Fast Loading

Fast Loading

Fast Loading 是一款 Minecraft 优化模组，专注于减少你的等待时间。

它的目标不只是加快启动速度。

Fast Loading 的设计目标是优化整个加载周期：

启动 Minecraft → 主菜单 → 世界/服务器 → 维度 → 资源包/光影 → 退出世界 → 主菜单

同时从以往的运行中学习，并在安全可复用的情况下避免不必要的重复工作。

初步预览

Fast Loading 目前处于首个预览阶段。

模组的基础部分已在开发中，但 Fast Loading 计划实现的许多深层加载优化，将在未来版本中逐步推出。

因此，性能提升可能会因以下因素而有所不同：

• 你的整合包；

• 硬件；

• 存储设备；

• Minecraft 配置；

• 以及目前已覆盖的加载瓶颈。

后续预览版本将继续扩展 Fast Loading 可优化的加载阶段。

Fast Loading 的优化目标

Fast Loading 正在开发中，旨在减少 Minecraft 完整加载周期中的等待时间，包括：

• Minecraft 启动

• Forge/模组加载

• 模组发现

• JAR 和元数据处理

• 类加载

• Mixin 和转换

• 资源加载

• 资源包重新加载

• 光影加载

• 进入世界

• 加入多人游戏服务器

• 维度切换

• 世界保存与退出

• 重复启动未更改的整合包

对于大型整合包而言，这一点尤其重要，因为其中相同的文件、模组和资源可能会在每次启动 Minecraft 时重复处理，造成大量不必要的工作。

自适应加载优化

Fast Loading 并非采用一套固定的优化策略来适配所有电脑。

不同系统的加载瓶颈可能截然不同。

例如，HDD、SATA SSD 和 NVMe SSD 可能适合不同的加载策略。

Fast Loading 正在开发中，将会监测以下因素：

• 加载时间；

• CPU 使用率；

• 内存使用量；

• 垃圾回收；

• 磁盘 I/O；

• 各个加载阶段；

• 故障和崩溃。

借助这些信息，Fast Loading 可以逐步判断哪些加载方式确实有助于当前环境。

长期的自适应循环如下：

观察
↓
找出瓶颈
↓
测试优化方案
↓
比较
↓
保留或回滚
↓
记住结果

这意味着 Fast Loading 不必假设理论上更快的优化就一定更好。

不再重复处理未更改的内容

Fast Loading 的一大重点是消除不必要的重复工作。

Minecraft 整合包可能包含数百甚至数千个 JAR、配置文件、元数据文件、资源和转换内容。

其中许多内容在多次启动之间可能完全相同。

Fast Loading 正在围绕以下系统进行开发：

• 持久化 JAR 索引；

• 元数据与解析缓存；

• 增量式模组发现；

• 依赖感知式失效处理；

• 安全复用转换结果；

持久化资源索引；

• 可重复使用的世界元数据；

• 针对特定环境的加载知识。

重要原则是：

已经完成且未发生变化的工作，不该永远都需要重新发现。

与此同时，只有在 Fast Loading 能确认相关环境仍然匹配时，才会重复使用缓存信息。

如果发生变化，尽可能只重新计算受影响的信息。

安全优先的缓存机制

Fast Loading 的目标是成为 Adaptive Mods 生态中最安全的优化模组之一。

它主要负责优化加载工作所需的开销，而不是改变 Minecraft 或其他模组原本应有的行为。

Fast Loading 的设计遵循一条简单原则：

如果无法证明缓存或优化后的工作可以安全复用，就执行常规工作。

该模组绝不会为了提升速度而刻意：

• 跳过必要的模组初始化；

• 改变游戏行为；

• 更改配方或机制；

• 修改玩家设置；

• 返回已知过期的缓存数据；

• 绕过必要的存档操作；

• 在必要工作实际完成前，假装加载已经完成。

缓存未命中可以接受。

重新计算也可以接受。

不能为了更快而使用错误的数据。

这种谨慎的做法尤为重要，因为 Fast Loading 涉及初始化、资源、世界等多个领域；在这些方面错误地复用数据，可能会引发难以排查的兼容性问题。

持久化与增量缓存

Fast Loading 无意创建一个庞大的缓存，然后不加判断地永久复用。

缓存信息应与决定其有效性的条件相关联。

根据具体系统，这些条件可能包括：

• 文件指纹；

• 模组版本；

• Minecraft 版本；

• 加载器版本；

• 相关配置；

• 转换输入；

• 环境标识；

• 硬件特征。

如果必要输入发生变化：

缓存命中 → 变为缓存未命中

受影响的信息便可以按常规方式重新构建。

长期目标是实现越来越精确的失效机制：

一项内容发生变化
↓
使依赖它的内容失效
↓
保留所有其他仍然有效的内容

而不是：

一项内容发生变化 → 删除所有内容。

为大型整合包而设计

Fast Loading 的开发目标涵盖从相对小型的整合包，到安装了数百个乃至可能超过：

1,000 个模组

大型整合包尤其值得关注，因为细小的重复开销累积起来，可能会增加数分钟的加载时间。

因此，其架构还必须确保 Fast Loading 本身不会成为瓶颈。

它的：

• 缓存大小；

• 内存占用；

• 磁盘占用；

• 后台任务；

• 索引；

• 加载历史记录

都必须保持在可控范围内，并随着整合包规模扩大而继续发挥作用。

如果 Fast Loading 为了节省 30 秒加载时间，却需要占用数 GB 的多余缓存或过多内存，那就称不上好的优化。

不同硬件需要不同策略

Fast Loading 也旨在根据运行它的设备调整自身行为。

一台配置较低的电脑，可能具有：

• 有限的内存；

• 较少的 CPU 线程；

• HDD 或 SATA SSD

不一定适合采用与以下系统相同的加载策略：

• 多个 CPU 核心；

• 大量内存；

• 高速 NVMe 硬盘。

例如，大幅提高磁盘读取的并行度，可能会让一台电脑受益，却让另一台电脑的速度明显变慢。

因此，Fast Loading 的长期目标并不是：

最大化并行度

而是：

为当前设备和整合包选择最有效的加载策略。

世界加载

Fast Loading 的优化范围不止于启动 Minecraft。

进入世界也是一个重要的优化目标。

未来的系统可以逐步优化以下相关工作：

• 发现世界；

• level.dat；

• 数据包；

• 注册表；

• 集成服务器启动；

• 模组持久化数据；

• 资源同步；

• 区块相关的准备工作。

在玩家进入常用世界之前，也可以预先准备好安全且可复用的世界信息。

目标是减少按下以下按钮后必须完成的工作量：

进入选中的世界

同时确保存档正确无误。

多人游戏

Fast Loading 也将优化连接多人游戏服务器时在本地执行的工作。

潜在的优化领域包括：

• 已知服务器的预先准备；

• 资源包；

• 本地注册表处理；

• 模组握手；

• 重复的资源处理；

• 可复用的本地服务器信息。

Fast Loading 无法消除实际的网络延迟，也无法让远程服务器本身更快地处理事务。

不过，它可以尝试减少因玩家自己的电脑执行相关工作而造成的不必要等待。

资源包与光影

在模组繁多的环境中，资源重载也可能变得极其耗时。

Fast Loading 的目标是最终优化以下内容的重复处理：

• 资源发现；

• 元数据；

• 模型；

• JSON；

• 图集输入；

• 纹理/资源索引；

• 光影预处理；

• 光影编译准备。

复用光影时，也必须考虑 GPU、驱动程序、光影包版本和渲染模组等相关兼容因素。

Fast Loading 绝不能盲目假设 GPU 相关状态在不同环境间始终兼容。

维度转换

Fast Loading 也计划学习重复发生的维度转换。

例如：

主世界 → 下界

所需的准备工作可能与以下情况不同：

主世界 → 大型模组维度

如果 Fast Loading 能在转换发生前安全地预测可能需要执行的工作，那么在严格的资源预算限制下，最终或许可以提前进行部分准备。

准备工作的规模可以根据设备情况调整。

内存较少的电脑应当比拥有大量闲置资源的系统少做很多准备。

更快地退出世界

加载优化也适用于离开游戏时。

Fast Loading 计划研究以下操作期间执行的工作：

• 保存世界；

• 序列化；

• 压缩；

• 磁盘写入；

• 集成服务器关闭；

• 清理资源。

在安全的情况下，可以在游戏过程中逐步准备部分工作，而不是等到玩家按下：

保存并退出到标题界面

但耐久性始终比看起来更快重要。

在必要的保存操作实际完成之前，Fast Loading 绝不能声称世界已安全关闭。

在不同整合包之间学习

某些加载方面的经验可能适用于不同环境。

例如，Fast Loading 可能会了解到，某种 I/O 策略在特定硬件配置上通常表现更好。

之后，这些经验可以影响它在其他环境中优先测试哪些策略。

不过：

从其他整合包迁移来的知识只是先验参考，并不能自动证明策略有效。

在整合包 A 中奏效的策略，在整合包 B 中成为权威方案之前，仍应经过验证。

这样，Fast Loading 就能从过往经验中学习，同时不预设每个整合包的行为都完全相同。

与 Adaptive Optimization 的关系

Adaptive Optimization 仍在积极开发中。

Fast Loading 现在开始开发，是因为 AO 已经确立了许多自适应优化系统所需的架构理念。

这些经验包括：

• 环境标识；

• 来源追溯；

• 自适应学习；

• 多维评估；

• 回滚；

• 有界工作集；

• 自身开销控制；

• 知识迁移；

• 语义保留。

Fast Loading 可以实现这些理念中规模更小、针对性更强的版本，而不必从零开始摸索。

Fast Loading 的设计目标是独立运行。

Fast Loading 不需要 Adaptive Optimization。

未来，Adaptive Optimization、Fast Loading 和其他 Adaptive Mods 可能会交换有用的证据与知识，同时仍作为彼此独立的优化器运行。

Fast Loading 也能加快开发本身

Fast Loading 此时启动开发还有另一个重要原因。

开发和测试优化模组需要反复执行：

构建
↓
启动 Minecraft
↓
加载整合包
↓
进入世界
↓
测试
↓
重启

对于大型整合包，开发时间中相当一部分可能只是在等待。

随着 Fast Loading 不断改进，它可以缩短这一迭代周期。

这意味着它最终可以帮助加快以下项目的测试：

• Adaptive Optimization；

• Fast Loading 本身；

• 未来的 Adaptive Mods。

因此，Fast Loading 既是面向玩家的优化项目，也有望成为整个生态开发流程中的重要组成部分。

当前状态

这是 Fast Loading 的初始预览版。

目前首先在搭建基础框架：

环境标识
↓
加载遥测
↓
持久化加载知识
↓
有界缓存
↓
自适应策略
↓
实验
↓
晋升 / 回滚

在此基础上，后续开发将逐步深入到：

模组发现
↓
元数据解析
↓
类加载
↓
ASM / Mixins
↓
资源
↓
世界
↓
服务器
↓
维度
↓
光影
↓
保存并退出

我们的目标不是伪造瞬间加载。

我们的目标是在确保安全的前提下，尽可能减少真正不必要的加载工作。

Discord

欢迎参与开发讨论、测试、提出建议和报告错误：

https://discord.gg/9WZDxVY4m

性能报告尤其有帮助。

如果可以，请说明 Fast Loading 是否：

• 改善了加载速度；

• 没有带来明显差异；

• 导致性能退化；

• 在多次启动后表现有所不同。

来自低端设备和超大型整合包的反馈尤其有价值。

Fast Loading 才刚刚起步。

它的长期目标很简单：

在确保安全的前提下，让大型模组整合版 Minecraft 尽可能少花时间等待。