Reduce duplicative instantiation of logic in SeqAccess and MapAccess #1205
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.
Measured in https://github.com/serde-rs/json-benchmark using
cargo llvm-lines --bin json-benchmark --no-default-features --features parse-struct,lib-serde,all-files --filter 'next_element_seed|next_key_seed'
, this PR reduces LLVM lines by 53% (compared to 37% for #1102). This is the part of the logic that needs to be instantiated separately per seq/map type, as opposed to once per Read type.Across the whole json-benchmark program, this PR decreases total LLVM lines by 8.8% (compared to 5.6% for #1102) and decreases function instantiations by 3.4%.
Benchmarked using
cargo build --release --bin json-benchmark --no-default-features --features parse-struct,lib-serde,all-files
, there is no statistically significant performance difference at runtime. (But I notice some opportunities to improve performance of the code in these functions. Leaving for a future PR.)Also benchmarked using the following microbenchmark that targets this code specifically, which likewise shows no regression.
Closes #1102.