Uh oh!
There was an error while loading. Please reload this page.
Conversation
Closed
phadej
commented
Feb 9, 2023
CollaboratorAuthor
For now these additions would live only in |
phadejforce-pushed
the
tokens
branch
2 times, most recently
from
February 10, 2023 15:09
20e4c54 to
bed9420CompareThere are two motivation points: 1. it's faster 2. it's more expressive The first point is actually accidental, but nevertheless very nice to have. In benchmarks decoding strict bytestring through Tokens seems to be 30% or so faster for examples we have: ``` Examples decode github-issues lazy: OK (0.14s) 2.03 ms ± 168 μs strict: OK (0.25s) 1.94 ms ± 180 μs tokens: OK (0.34s) 1.27 ms ± 61 μs Twitter decode Generic direct twitter100: OK (1.30s) 2.43 ms ± 161 μs jp100: OK (0.25s) 2.09 ms ± 126 μs twitter100t: OK (0.33s) 1.34 ms ± 121 μs jp100t: OK (0.17s) 1.37 ms ± 86 μs Manual direct twitter100: OK (0.21s) 1.76 ms ± 86 μs jp100: OK (0.30s) 2.29 ms ± 207 μs twitter100t: OK (0.74s) 1.38 ms ± 33 μs jp100t: OK (0.20s) 1.61 ms ± 125 μs TH direct twitter100: OK (0.27s) 2.08 ms ± 180 μs jp100: OK (0.54s) 2.17 ms ± 149 μs twitter100t: OK (0.36s) 1.38 ms ± 50 μs jp100t: OK (0.39s) 1.48 ms ± 49 μs ``` The second point is also quite important. If some users really need to know the order of key-value pairs in a JSON object, or care whether number was integral, decimal or scientific; now they can differentiate. Though they cannot use `FromJSON` machinery, this is a start. E.g. issues like *Should we make a clear value-level distinction between floating and integral numbers?* #546 (For `Value` it would be bad, for `Tokens` it's fine).
CollaboratorAuthor
The lazy bytestring token decoder is also fast, but slower than using strict bytestring as input. |
phadej
commented
Feb 10, 2023
CollaboratorAuthor
I also run the benchmark with |
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There are two motivation points:
The first point is actually accidental, but nevertheless very nice to have. In benchmarks decoding strict bytestring through Tokens seems to be 30% or so faster for examples we have:
The second point is also quite important.
If some users really need to know the order of key-value pairs in a JSON object, or care whether number was integral, decimal or scientific; now they can differentiate.
Though they cannot use
FromJSONmachinery, this is a start.E.g. issues like Should we make a clear value-level distinction between floating and integral numbers?#546 (For
Valueit would be bad, forTokensit's fine).