Experimental Performance - 实验性性能优化

内存分配

某些类可能非常占用内存，它们的内存占用很大。

这是个问题，因为你的处理器缓存行只能容纳64字节，任何超过64字节的内容都需要分割到多个缓存行中。这会根据调用内容大幅降低操作速度。

显然最佳解决方案是确保没有任何内容超过64字节，但这说起来容易做起来难，因为这种做法存在多个缺点——尽管在我优化的场景下这些缺点并不重要。

区块内存分配

区块非常占用内存，达到80字节。通过一些巧妙的Fabric-ASM技术，我们能够移除区块类中的变量并重定向所有调用。

这使区块大小恢复至64字节，在某些计算机上可使多数区块操作速度提升至原来的1.25倍！

方块内存分配

方块同样非常占用内存，达到72字节。

我们采用与区块相同的方法，将内容移至BlockInfo类中并减轻原类的负担。

这不仅使多数方块能更快传递，还能防止某些方块超过128字节（否则将需要占用3个缓存行）。

实体内存分配

与区块和方块不同，实体类堪称噩梦。它占用272字节，相当于5个缓存行。难怪实体会造成卡顿 xD

我已将其优化至4个缓存行，但进一步优化将破坏更多模组兼容性，我目前没有时间处理。

如果这个模组将来发展得足够大，我可能会重写整个实体类，并为你需要的数值提供API接口。

为什么Mojang不这样做？

其实他们某种程度上也在做？

在进行优化时，我注意到Mojang实际上已经实施了与我相同的性能改进。比如LevelInfo类，不过那是几年前的事了？

Mojang如今似乎不太关心性能问题，他们做出了一些非常奇怪的性能调整，但似乎从未真正重视。某些类在过去几年里变得臃肿不堪，而他们并未注意到这些类已变得如此庞大。

不过这没关系，因为有我来帮忙解决。

猫鼠游戏

提升性能是困难的，这是个非常复杂的难题，需要你深入理解每个细节。

简而言之，计算机并不简单。它们努力让程序员不必过多思考这些问题，但程序员其实应该时刻保持思考。

我在说什么？

通过这个模组获得的性能是有代价的——额外的调用和内存分配。我只是在优化游戏内部结构，使其能与计算机更流畅快速地协作，但这需要计算机记住更多内容。

幸运的是，你通常不会察觉到这个代价，因为在大多数情况下，性能提升远远超过了损失。

实验性说明！！！

看来我需要反复强调这一点。本模组具有高度实验性，通过巧妙的ASM技术重新调整类结构来提升性能。请勿将其包含在模组包中，也不要提交兼容性问题报告。本模组是作为概念验证而开发的，旨在探索能否通过减小缓存行中的类大小来进一步优化Minecraft。虽然本模组已显示出明显的性能提升，但其测试尚不充分，仍需大量改进工作。目前我没有时间继续开发这个模组。