快速 NBT使 Minecraft 持续执行的 NBT 工作成本更低：读取标签、将其转换为游戏对象，以及从区块、数据包、方块状态和物品堆栈中加载它们。
快速 NBT 使 Minecraft 持续执行的 NBT 工作成本更低：读取标签、将其转换为游戏对象，以及从区块、数据包、方块状态和物品堆栈中加载它们。 CompoundTag（复合标签） 各种 get 方法。 在原版游戏中，它首先调用 contains 以检查键是否存在，然后调用 get ——两次映射查找。Fast NBT 将这两个操作合并为一个并应用内联，从而大大提高了查找速度。 迭代。 使用 keySet 与 get 结合的迭代被一种同时遍历键和值的方法所取代，因此写入和合并复合标签不再对每个条目进行查找。 相关类。 其他相关类中使用这些 get 方法的优化也得到了优化。 物品堆栈、方块状态和 NBT I/O 物品堆栈加载。 从 NBT 读取一个 ItemStack 需要从支持映射中直接获取 tag 和 ForgeCaps ，而不是通过两次 contains 调用进行探测，并且 getOrCreateTagElement , getTagElement 和 removeTagKey 在一次查找中解析。 方块状态。 NbtUtils.readBlockState 和 getDataVersion 直接读取 Name 和 Properties ，而不是经过原版的 contains / getString 链。 区块部分调色板。 每个调色板条目通常要经过完整的 DFU 编解码器链——分派编解码器、注册表查找、每个属性一个 MapCodec ，加上 DataResult / Either / Pair / Optional 分配——在每次区块加载和每次保存时都会如此。Fast NBT 直接从映射中解析规范的 {Name, Properties} 标签。这是该模组最大的收益。 NBT I/O。 无限制读取器——每次区块加载，以及 level.dat 和玩家数据——跳过其结果被丢弃的字节计数传递。 因此，收益出现在批量解码 NBT 的地方：世界和区块加载、服务器自动保存（重新编码每个区块），以及携带标记 ItemStack 的物品、方块实体和实体载荷。调色板路径上临时对象的减少也意味着更低的 GC 压力。 这不是一款通用的性能模组：它不触及 NBT 之外的任何内容，也无法帮助受磁盘或网络限制的工作负载。节省效果随着包解码的 NBT 量而增加，在纯原版世界中最小。 配置 config/fastnbt.toml 在首次启动时生成，并为每个优化提供自己的开关： enabled = true # master switch for everything below [features.itemStack] enabled = true [features.blockState] enabled = true [features.blockStateCodec] enabled = true [features.nbtIo] enabled = true The CompoundTag 重写没有单独的开关；全局 enabled 标志控制它们。 如何保持安全 只有规范数据走快速路径。 任何非规范数据都被报告为解码错误，而不是被猜测，并且 Properties 中方块不存在的键会被忽略，这与原版完全相同。对于区块调色板，调用者将失败的条目转换为空气，因此引用未安装模组中方块的世界仍然可以加载——每个条目有一条日志行。 编码从未被替换。 调色板优化仅加速解码，因此保存的区块和网络数据包保持字节完全相同。 注入冲突。 优化替换或重定向原版方法，不提供非破坏性变体，因此如果另一个模组针对相同的方法，最后应用的胜出。在发布大型模组包之前进行测试。 根据 GNU LGPL v3.0 或更高版本授权。
在鱼乐云资源中心浏览该资源,登录后可一键安装到你的游戏服务器。