Improve performance of clearAllBlockInfoAtChunk, don't get immutable map

[WalshyDev]

Description

We're currently getting our ImmutableMap clone in clearAllBlockInfoAtChunk, instead we can unsafely get the storage and save the overhead of duplicating the map (which for large servers is massive).

Right now it's taking basically all of the compute time:

Proposed changes

Unsafely get the raw storage instead of our safe ImmutableMap.

Related Issues (if applicable)

Resolves #3432

Checklist

• I have fully tested the proposed changes and promise that they will not break everything into chaos.
• I have also tested the proposed changes in combination with various popular addons and can confirm my changes do not break them.
• I have made sure that the proposed changes do not break compatibility across the supported Minecraft versions (1.16.* - 1.20.*).
• I followed the existing code standards and didn't mess up the formatting.
• I did my best to add documentation to any public classes or methods I added.
• I have added Nonnull and Nullable annotations to my methods to indicate their behaviour for null values
• I added sufficient Unit Tests to cover my code.

[github-actions]

Your Pull Request was automatically labelled as: "🧹 Chores"
Thank you for contributing to this project! ❤️

[WalshyDev]

cc: @md5sha256 - not sure if you had any specific reason to use getRawStorage instead of accessing it directly.
I believe we should be safe to use this though, we're only doing reads, not attempting any writes and aren't passing the ref down anywhere.

[github-actions]

Slimefun preview build

A Slimefun preview build is available for testing!
Commit: 1b2eb20b

https://preview-builds.walshy.dev/download/Slimefun/3905/1b2eb20b

Note: This is not a supported build and is only here for the purposes of testing.
Do not run this on a live server and do not report bugs anywhere but this PR!

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[WalshyDev]

Timing courtesy of @Skizzles - https://spark.lucko.me/5ZX5HHHvHi

clearAllBlockInfoAtChunk went from 52.67% 44440ms (self: 3404ms - 4.03%) -> 32.51% 11580ms (self: 112ms - 0.31%)

44s -> 11s

We're now hitting Javaland code taking the rest of the majority:

22.03% (7.8s) from ConcurrentHashMap.get()

BlockStorage rewrite wen:tm:

[md5sha256]

cc: @md5sha256 - not sure if you had any specific reason to use getRawStorage instead of accessing it directly. I believe we should be safe to use this though, we're only doing reads, not attempting any writes and aren't passing the ref down anywhere.

Either an oversight or I was erring on the side of caution. Either way, the performance benefit outweighs the perceived safety of operating on #getRawStorage

The only comment I have-ish, (and I've never done this, there was a reason why) but is it good practice/possible to just store (cache) the immutable map in the BlockStorage instance since it's basically just a wrapper? This might become obsolete in the future, however.

[WalshyDev]

The only comment I have-ish, (and I've never done this, there was a reason why) but is it good practice/possible to just store (cache) the immutable map in the BlockStorage instance since it's basically just a wrapper? This might become obsolete in the future, however.

probably but we'd really want to have partial updates done when needed to it (which kinda breaks the immutable part as it isn't fully) and afaik you can't do that with any Java-native implementations today.

There's also just the issue of added memory :(

[md5sha256]

Yeah, fair enough. In that case LGTM

[JustAHuman-xD]

LGTM