ruby.git/ext/json/fbuffer, branch v3_4_9

[ruby/json] JSON.dump: write directly into the provided IO

2024-11-26T06:11:05+00:00

Ref: https://github.com/ruby/json/issues/524

Rather than to buffer everything in memory.

Unfortunately Ruby doesn't provide an API to write into
and IO without first allocating a string, which is a bit
wasteful.

https://github.com/ruby/json/commit/f017af6c0a

[ruby/json] Resync

2024-11-05T17:00:36+00:00

JSON.generate: call to_json on String subclasses

2024-11-01T04:04:24+00:00

Fix: https://github.com/ruby/json/issues/667

This is yet another behavior on which the various implementations
differed, but the C implementation used to call `to_json` on String
subclasses used as keys.

This was optimized out in e125072130229e54a651f7b11d7d5a782ae7fb65
but there is an Active Support test case for it, so it's best to
make all 3 implementation respect this behavior.

[ruby/json] Make fbuffer_inc_capa easier to inline

2024-11-01T04:04:24+00:00

With the extra logic added for stack allocation, and especially the
memcpy, it became harder for compilers to inline.

This doesn't fully reclaim the speed lost with the stack allocation,
but it's getting closer.

Before:

```
== Encoding twitter.json (466906 bytes)
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
                json   160.000 i/100ms
                  oj   225.000 i/100ms
Calculating -------------------------------------
                json      1.577k (± 2.0%) i/s  (634.20 μs/i) -      8.000k in   5.075561s
                  oj      2.264k (± 2.3%) i/s  (441.79 μs/i) -     11.475k in   5.072205s

Comparison:
                json:     1576.8 i/s
                  oj:     2263.5 i/s - 1.44x  faster

== Encoding citm_catalog.json (500298 bytes)
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
                json   101.000 i/100ms
                  oj   123.000 i/100ms
Calculating -------------------------------------
                json      1.033k (± 2.6%) i/s  (968.06 μs/i) -      5.252k in   5.087617s
                  oj      1.257k (± 2.2%) i/s  (795.54 μs/i) -      6.396k in   5.090830s

Comparison:
                json:     1033.0 i/s
                  oj:     1257.0 i/s - 1.22x  faster
```

After:

```
== Encoding twitter.json (466906 bytes)
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) [arm64-darwin23]
Warming up --------------------------------------
                json   213.000 i/100ms
                  oj   230.000 i/100ms
Calculating -------------------------------------
                json      2.064k (± 3.6%) i/s  (484.44 μs/i) -     10.437k in   5.063685s
                  oj      2.246k (± 0.7%) i/s  (445.19 μs/i) -     11.270k in   5.017541s

Comparison:
                json:     2064.2 i/s
                  oj:     2246.2 i/s - 1.09x  faster

== Encoding citm_catalog.json (500298 bytes)
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) [arm64-darwin23]
Warming up --------------------------------------
                json   133.000 i/100ms
                  oj   132.000 i/100ms
Calculating -------------------------------------
                json      1.327k (± 1.7%) i/s  (753.69 μs/i) -      6.650k in   5.013565s
                  oj      1.305k (± 2.2%) i/s  (766.40 μs/i) -      6.600k in   5.061089s

Comparison:
                json:     1326.8 i/s
                  oj:     1304.8 i/s - same-ish: difference falls within error
```

https://github.com/ruby/json/commit/89f816e868

[ruby/json] Allocate the initial generator buffer on the stack

2024-11-01T04:04:24+00:00

Ref: https://github.com/ruby/json/issues/655
Followup: https://github.com/ruby/json/issues/657

Assuming the generator might be used for fairly small documents
we can start with a reasonable buffer size of the stack, and if
we outgrow it, we can spill on the heap.

In a way this is optimizing for micro-benchmarks, but there are
valid use case for fiarly small JSON document in actual real world
scenarios, so trashing the GC less in such case make sense.

Before:

```
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
                  Oj   518.700k i/100ms
          JSON reuse   483.370k i/100ms
Calculating -------------------------------------
                  Oj      5.722M (± 1.8%) i/s  (174.76 ns/i) -     29.047M in   5.077823s
          JSON reuse      5.278M (± 1.5%) i/s  (189.46 ns/i) -     26.585M in   5.038172s

Comparison:
                  Oj:  5722283.8 i/s
          JSON reuse:  5278061.7 i/s - 1.08x  slower
```

After:

```
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
                  Oj   517.837k i/100ms
          JSON reuse   548.871k i/100ms
Calculating -------------------------------------
                  Oj      5.693M (± 1.6%) i/s  (175.65 ns/i) -     28.481M in   5.004056s
          JSON reuse      5.855M (± 1.2%) i/s  (170.80 ns/i) -     29.639M in   5.063004s

Comparison:
                  Oj:  5692985.6 i/s
          JSON reuse:  5854857.9 i/s - 1.03x  faster
```

https://github.com/ruby/json/commit/fe607f4806

[ruby/json] Allocate the FBuffer struct on the stack

2024-10-30T01:13:48+00:00

Ref: https://github.com/ruby/json/issues/655

The actual buffer is still on the heap, but this saves a pair
of malloc/free.

This helps a lot on micro-benchmarks

Before:

```
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
                  Oj   531.598k i/100ms
          JSON reuse   417.666k i/100ms
Calculating -------------------------------------
                  Oj      5.735M (± 1.3%) i/s  (174.35 ns/i) -     28.706M in   5.005900s
          JSON reuse      4.604M (± 1.4%) i/s  (217.18 ns/i) -     23.389M in   5.080779s

Comparison:
                  Oj:  5735475.6 i/s
          JSON reuse:  4604380.3 i/s - 1.25x  slower
```

After:

```
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
                  Oj   518.700k i/100ms
          JSON reuse   483.370k i/100ms
Calculating -------------------------------------
                  Oj      5.722M (± 1.8%) i/s  (174.76 ns/i) -     29.047M in   5.077823s
          JSON reuse      5.278M (± 1.5%) i/s  (189.46 ns/i) -     26.585M in   5.038172s

Comparison:
                  Oj:  5722283.8 i/s
          JSON reuse:  5278061.7 i/s - 1.08x  slower
```

Bench:

```ruby
require 'benchmark/ips'
require 'oj'
require 'json'

json_encoder = JSON::State.new(JSON.dump_default_options)
test_data = [1, "string", { a: 1, b: 2 }, [3, 4, 5]]

Oj.default_options = Oj.default_options.merge(mode: :compat)

Benchmark.ips do |x|
  x.config(time: 5, warmup: 2)

  x.report("Oj") do
    Oj.dump(test_data)
  end

  x.report("JSON reuse") do
    json_encoder.generate(test_data)
  end

  x.compare!(order: :baseline)
end
```

https://github.com/ruby/json/commit/72110f7992

[ruby/json] Optimize `fbuffer_append_long`

2024-10-29T04:25:01+00:00

Ref: https://github.com/ruby/json/issues/655

Rather than to write the number backward, and then reverse
the buffer, we can start from the back of the buffer and write
the number in the proper direction.

Before:

```
== Encoding integers (8009 bytes)
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
                json     8.606k i/100ms
                  oj     9.598k i/100ms
Calculating -------------------------------------
                json     86.059k (± 0.8%) i/s   (11.62 μs/i) -    430.300k in   5.000416s
                  oj     97.409k (± 0.6%) i/s   (10.27 μs/i) -    489.498k in   5.025360s

Comparison:
                json:    86058.8 i/s
                  oj:    97408.8 i/s - 1.13x  faster
```

After:

```
== Encoding integers (8009 bytes)
ruby 3.3.4 (2024-07-09 revision https://github.com/ruby/json/commit/be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
        json (reuse)     9.500k i/100ms
                json     9.359k i/100ms
                  oj     9.722k i/100ms
Calculating -------------------------------------
        json (reuse)     96.270k (± 0.4%) i/s   (10.39 μs/i) -    484.500k in   5.032777s
                json     94.800k (± 2.2%) i/s   (10.55 μs/i) -    477.309k in   5.037495s
                  oj     97.131k (± 0.7%) i/s   (10.30 μs/i) -    486.100k in   5.004822s

Comparison:
        json (reuse):    96270.1 i/s
                  oj:    97130.5 i/s - same-ish: difference falls within error
                json:    94799.9 i/s - same-ish: difference falls within error
```

https://github.com/ruby/json/commit/0655b58d14

[ruby/json] Get rid of some more outdated compatibility code

2024-10-17T13:02:13+00:00

All these macros are available on Ruby 2.3+

https://github.com/ruby/json/commit/227885f460

[ruby/json] Stop prebuilding object_delim2

2024-10-17T08:54:47+00:00

Also, remove static functions that are no longer used.

This speeds up `JSON.generate` by about 5% in a benchmark.

https://github.com/ruby/json/commit/4c984b2017

[flori/json] Optimize `fbuffer_inc_capa`

2024-10-03T05:20:34+00:00

On my `JSON.dump` benchmark it shows up as 6% of runtime, compared
to 40% for `convert_UTF8_to_JSON`.

Since the vast majority of the time this function is called we
still have some buffer capacity, we might as well check that
first and skip the expensive loop etc.

With this change my profiler now report this function as 0.7%,
so almost 10x better.

https://github.com/flori/json/commit/a7206bf2db