if there's no state data to encode, we can avoid useless calls and object allocations.
For the best cases (blocks which don't use state data at all) this improves the performance of getStateId() by more than 10x.
Blocks which use one or the other benefit by a smaller but still significant margin.
closes#6070
there are some unresolved questions about the growth speed of beetroots, pitcher plants and torchflower crops, but that's a topic for another commit.
this change also doesn't account for the light levels.
during unset(), the destructors for other objects with cyclic references can get triggered, resulting in the functions being reentered before the count() call. This leads to a crash because the offset no longer exists.
Instead, we check if only the given PermissibleInternal is present, and clean everything up with a single unset instead of two.
This could also have been solved by adding extra isset() checks before checking the counts, but this way seemed more elegant.
This is similar to an issue with AsyncTask thread-local storage a few months ago, which was also caused by GC reentrancy.
closes#6119
for some reason the isSpectator() call here can take upwards of 2 microseconds, for no obvious reason. Subsequent calls are much faster, so I think there's some weird cache thing going on here.
This reverts commit 8f804f6f34.
This change is too disruptive, since popular plugins like
ExtendedBlocks and ExtendedBlocksConverter relied on custom tiles.
Deleting them at this stage would prevent these plugins from working,
making it impossible to upgrade old data.
An alternative solution to this problem will need to be developed.
The old code was allocating 6 Vector3s which were all immediately discarded. In addition, we didn't need to take the performance hit of reading Vector3 properties when we could have just passed integers directly.
The real performance difference of this is likely to be close to zero, but it's still worth doing.
closes#6104
This function has been a footgun for anyone using it, since it also returns entity AABBs by default.
In all core use cases, this functionality was disabled, and we were paying a needless (admittedly micro) performance penalty for passing the extra useless argument and useless condition check.
Farmland can end up scanning up to 162 blocks looking for water in the worst case. This is obviously not great for huge farms where there are thousands of blocks of the stuff.
In most farms, the water won't be moved, and nor will the farmland. This means that we can avoid this costly search on random updates.
This PR implements a cache using blockstate data (only possible in PM5) which stores an index mapping to a coordinate offset where water was previously found by this farmland block. This allows the farmland to avoid water searching entirely in most cases.
This is a colossal improvement as compared to scanning the whole 9x2x9 area every time, which, on average, scans about 40 blocks to find water if the water is at the same Y coordinate. In real terms this translates into about a 8x performance improvement for farmland (see timings below).
