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
One of the annoying properties of NBT is that the entire thing has to be parsed in order to know how long it is, because a length prefix usually isn't included where it's used.
It's also very annoying to need to decode an entire NBT file (sometimes many MBs of data) just to get at perhaps a specific data key.
It would be nice to introduce an NbtIndexer that would take an input file and build an index of where to find all the tags in it, instead of decoding all those tags directly into objects. Then, when a specific subset of the data wants to be accessed, it would lookup the byte offset in the index, and then deserialize only that specific part of the file.
This would mainly be useful for processing large amounts of data when only a small amount of it is actually wanted.
It's not currently clear to me how useful this would actually be in terms of performance, but it's an experiment I thought might be worth someone's time to investigate.
The text was updated successfully, but these errors were encountered:
One of the annoying properties of NBT is that the entire thing has to be parsed in order to know how long it is, because a length prefix usually isn't included where it's used.
It's also very annoying to need to decode an entire NBT file (sometimes many MBs of data) just to get at perhaps a specific data key.
It would be nice to introduce an
NbtIndexer
that would take an input file and build an index of where to find all the tags in it, instead of decoding all those tags directly into objects. Then, when a specific subset of the data wants to be accessed, it would lookup the byte offset in the index, and then deserialize only that specific part of the file.This would mainly be useful for processing large amounts of data when only a small amount of it is actually wanted.
It's not currently clear to me how useful this would actually be in terms of performance, but it's an experiment I thought might be worth someone's time to investigate.
The text was updated successfully, but these errors were encountered: