Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement deserializer cache for readonly tag types and TAG_Compound keys #110

Open
dktapps opened this issue Jul 8, 2022 · 3 comments
Open

Comments

@dktapps
Copy link
Member

dktapps commented Jul 8, 2022

During deserialization of complex NBT, we're likely to encounter NBT with many repeated values which could be cached.

For example, when deserializing a block palette file, the following types of tags are predominantly used:

  • TAG_Byte (used for true or false)
  • TAG_Int (commonly used for a small range)
  • TAG_String (commonly used for small enums)

Particularly in this case (since block state permutations are extremely repetetive) it could offer a significant memory usage advantage (and possibly performance) to keep a temporary lookup table of tag types and their values, so that the same Tag objects can be reused in different places.

For example, deserializing the current block palette (1.19.0) results in:

Type Count (without deduplicating) Count (with deduplicating)
TAG_String 18191 150
TAG_Int 3585 64
TAG_Byte 7168 2

This results in a considerable memory usage saving (16 MB -> 11 MB).

In addition, deduplication of TAG_Compound keys may also save a considerable amount of memory for complex NBT trees, due to frequently repeated keys.

@dktapps
Copy link
Member Author

dktapps commented Dec 27, 2022

In 1.19.50, this now makes a difference of 15 MB vs 22 MB in memory footprint, due to a significant increase in the number of blockstates.

@dktapps
Copy link
Member Author

dktapps commented May 3, 2023

It eventually occurred to me that the solution to this problem was to just ... not have NBT objects floating around at runtime.

@dktapps dktapps closed this as completed May 3, 2023
@dktapps dktapps reopened this Mar 5, 2024
@dktapps
Copy link
Member Author

dktapps commented Mar 6, 2024

A Tag object cache might be useful for improving performance of chunk reads in PM5, where blockstate NBT data has known possible values. These object allocations currently cost a lot of performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant