NTM Optimization Update!

[BallOfEnergy1]

The NTM Optimization Update is here!

Changes:
Completely removed the NBTPacket and INBTPacketReceiver classes in favor of using ByteBufs for everything.
Reworked RBMK and Chicago Pile neutron calculations, now they should be way more performant (and use the same system).
Tons of other small tweaks.

Profiler results:
100 Rod RBMK (made by nootles):
Before: 22.9 avg MSPT
After: 2.58 avg MSPT
Gerver (my personal server):
Before: 12.9 avg MSPT
After: 5.32 avg MSPT

Don't merge yet, still looking for a good place to check for every possible issue that could exist.
(sorry about the crazy commit structure, GitHub was being an asshole and wouldn't let me resolve conflicts)

[WushiThe]

chat is this real

[HbmMods]

Do you have any profiler data on the upgrade stuff? Because I'm not sure if caching that would even change a whole lot, considering often times machines run without upgrades anyway and machines only have 2-4 upgrade slots at most.

[kcinnaJlol]

would it be possible to process rbmks that can't interact with each other in seperate threads for more speed? or did you already implement that?

[BallOfEnergy1]

Multi threading RBMKs is possible, though it would have such a massive overhead for synchronizing them that it would be slower than with what we have right now.

[BallOfEnergy1]

Do you have any profiler data on the upgrade stuff? Because I'm not sure if caching that would even change a whole lot, considering often times machines run without upgrades anyway and machines only have 2-4 upgrade slots at most.

The main reason I even touched upgrades at all was because 70000hp mentioned that he noticed some speed issues when using that system since it checks every tick every upgrade slot, though I haven't seen any performance impacts of my own.

[HbmMods]

Upgrade checks are just for loops the size of the upgrade slot range (single digit) which either NOPs when no upgrades are installed or adding upgrade info to a hashmap (with at most as many elements as there are occupied slots), whatever the machine itself does (recipe lookup, port connections, etc) is likely magnitudes more impactful than that, which is why I'd prefer seeing profiler results first before changing anything with the upgrade system.

[BallOfEnergy1]

Alright, I'll try and see if I can get some profiler data on it this afternoon, as well as maybe looking into how to optimize other parts of machines.

[BallOfEnergy1]

With this most recent commit, the 100 rod RBMK time has been reduced to a mere 0.818 MSPT avg, as well as the memory usage being reduced by almost double due to optimizations with how the BlockPos instances are handled. This has not been tested fully with the gerver save yet, however my tests from a while ago suggest a 2x improvement over the already optimized version.

[BallOfEnergy1]

With this most recent commit, the 100 rod RBMK time has been reduced to a mere 0.818 MSPT avg, as well as the memory usage being reduced by almost double due to optimizations with how the BlockPos instances are handled. This has not been tested fully with the gerver save yet, however my tests from a while ago suggest a 2x improvement over the already optimized version.

This has since been improved to ~0.616 MSPT med, as well as memory usage being reduced from ~800MB before any optimizations and ~2100MB after MSPT optimizations, down to ~300MB (All tested on the 100 rod RBMK save).