-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make JSON.generate
1.75x as fast
#562
Conversation
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? |
|
||
for (p = ptr; (unsigned long)(p - ptr) < len;) { | ||
need_escape |= escapeTable[(int)*p++]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need_escape |= escapeTable[(int)*p++]; | |
need_escape |= escapeTable[(int)*p++]; | |
if (need_escape) break; |
This PR speeds up
JSON.generate
by approximately 1.75x (485k instructions per second -> 840k instructions per second) for the benchmark of Oj. This makesJSON.generate
nearly as fast asOj.dump
.Before:
After:
This PR consists of the following several improvements.
Drop prebuild of
array_delim
, etc.array_delim
is usually a single comma character. Usingmemcpy
to copy a single character was inefficient.array_nl
separately 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_string
for object keys.generate_json
in 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.