Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Low-level encoders (C++) can achieve greater performance by pre-encoding object keys together with their corresponding length (e.g.
[[] [U] [3] [foo] [T] []]=>[U] [3] [foo]) and directly writing this to the output stream instead of generating it on the fly. This method is currently used in glaze to speed up encoding in BEVE.The decoding side is currently unable to benefit from this because the standard allows key lengths to be encoded using any integer marker, signed or unsigned, right sized or oversized - meaning the decoder must be ready for whatever comes its way even if it is not the most optimal coding.
This proposal introduces restrictions on the type of markers which may be used for a length, namely only the 4 unsigned integer types (
uint8,uint16,uint32anduint64), applicable across strings, arrays, keys, huge numbers.Object keys are further restricted in that they must use the smallest length marker type that can represent the length of the key. This makes sense because keys are effectively constant values. Keys do not benefit from any in-place modification abilities because they are always directly followed by a value, which must move together with the end of the key - whether it be due to the key length itself changing or the key length marker changing between different sizes.
Arrays/strings/others are not subjected to this restriction as they do benefit from in-place modification, and are not usually storing constants.