Make JSON.generate 1.75x as fast
#562
Open
Conversation
This file contains 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
The purpose of this change is to exploit `fbuffer_append_char` that is faster than `fbuffer_append`. `array_delim` was a buffer that concatenated a single comma with `array_nl`. However, in the typical use case (`JSON.generate(data)`), `array_nl` is empty. This means that `array_delim` was a single-character buffer in many cases. `fbuffer_append(buffer, array_delim)` used `memcpy` to copy one byte, which was not so efficient. Rather, this change uses `fbuffer_append_char(buffer, ',')` and then `fbuffer_append(buffer, array_nl)` only when `array_nl` is not NULL. This speeds up `JSON.generate` by about 9% in a benchmark.
This speeds up `JSON.generate` by about 4% in a benchmark
Also, remove static functions that are no longer used. This speeds up `JSON.generate` by about 5% in a benchmark.
This speeds up `JSON.generate` by about 4% in a benchmark.
This speeds up `JSON.generate` by about 12% in a benchmark.
... instead of `rb_enc_str_asciionly_p`. If escaping is not needed, we can use `fbuffer_append` directly, which is much faster. This speeds up `JSON.generate` by about 16% in a benchmark.
Dispatching based on Ruby's VALUE structure is more efficient than simply cascaded "if ... else if ..." checks. This speeds up `JSON.generate` by about 5% in a benchmark.
... instead of `generate_json`. Since the object key is already confirmed to be a string, using a generic dispatch function brings an unnecessary overhead. This speeds up `JSON.generate` by about 3% in a benchmark.
It is safe to use `RARRAY_AREF` here because no Ruby code is executed between `RARRAY_LEN` and `RARRAY_AREF`. This speeds up `JSON.generate` by about 4% in a benchmark.
|
Note: I got |
|
I will re-run https://github.com/flori/json/actions/runs/7336797514/job/19976695584?pr=562 after supporting Ruby 3.3 at |
|
I'd love to see this merged, @hsbt could you take another look now that Ruby 3.3 is properly released? |
Sign up for free
to 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.
This PR speeds up
JSON.generateby approximately 1.75x (485k instructions per second -> 840k instructions per second) for the benchmark of Oj. This makesJSON.generatenearly as fast asOj.dump.Before:
After:
This PR consists of the following several improvements.
Drop prebuild of
array_delim, etc.array_delimis usually a single comma character. Usingmemcpyto copy a single character was inefficient.array_nlseparately without prebuild.Use faster Ruby API for encoding checks.
Use a fast path when string escaping is not needed.
Use faster Ruby API for dispatching the class of objects.
Use
generate_json_stringfor object keys.generate_jsonin general dispatch was an unnecessary overhead.Use faster Ruby API for reading array elements.
I made them into one PR because I thought separating this to multiple PRs would bring many conflicts between PRs. However, if you want me to do so, feel free to let me know.