You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the way we process palette loading is comically inefficient.
We have to convert whatever data we have into a PHP array of integers, which is subsequently converted into a native array after a bunch of slow, non-vectorizable range checks are done on each of the values. In the end, we actually just want a uint32_t[], so we could just accept a raw byte string with a length of a multiple of 4 instead.
This would be significantly faster for FastChunkSerializer, which currently has to involve useless arrays. (It would need to be accompanied by a function to get the palette as a string directly to avoid using pack() and more array conversions.)
For loading from disk, the benefit would be less significant, as we have to build up an array of blockstate IDs from converting NBT anyway, but the benefit of avoiding a throwaway array and a bunch of unnecessary bounds checks would probably be beneficial nonetheless.
The text was updated successfully, but these errors were encountered:
Currently, the way we process palette loading is comically inefficient.
We have to convert whatever data we have into a PHP array of integers, which is subsequently converted into a native array after a bunch of slow, non-vectorizable range checks are done on each of the values. In the end, we actually just want a uint32_t[], so we could just accept a raw byte string with a length of a multiple of 4 instead.
This would be significantly faster for FastChunkSerializer, which currently has to involve useless arrays. (It would need to be accompanied by a function to get the palette as a string directly to avoid using pack() and more array conversions.)
For loading from disk, the benefit would be less significant, as we have to build up an array of blockstate IDs from converting NBT anyway, but the benefit of avoiding a throwaway array and a bunch of unnecessary bounds checks would probably be beneficial nonetheless.
The text was updated successfully, but these errors were encountered: