Optimize internal extract! calls to save on memory allocation

[moberegger]

Simply optimizes internal calls to extract! to avoid extra memory allocations to splat the *attributes. Both _extract_hash_values and _extract_method_values accept an array for attributes, so no need to re-splat it by calling extract!, which then splats it again.

Solution is to implement a private _extract that just accepts an array, which can be used internally.

A simple way to compare it is with the call DSL, which was just running extract! underneath.

# person = { first_name: 'John', last_name: 'Doe', age: 30, city: 'New York' }

json.(person, :first_name, :last_name, :age, :city)

Warming up --------------------------------------
              before   156.678k i/100ms
               after   176.882k i/100ms
Calculating -------------------------------------
              before      1.674M (± 1.6%) i/s  (597.37 ns/i) -      8.461M in   5.055454s
               after      1.802M (± 2.0%) i/s  (554.82 ns/i) -      9.021M in   5.007138s

Comparison:
               after:  1802399.6 i/s
              before:  1673994.1 i/s - 1.08x  slower

Calculating -------------------------------------
              before   320.000  memsize (     0.000  retained)
                         6.000  objects (     0.000  retained)
                         4.000  strings (     0.000  retained)
               after   240.000  memsize (     0.000  retained)
                         5.000  objects (     0.000  retained)
                         4.000  strings (     0.000  retained)

Comparison:
               after:        240 allocated
              before:        320 allocated - 1.33x more

This change has no impact in using json.extract! directly.

# person = { first_name: 'John', last_name: 'Doe', age: 30, city: 'New York' }

json.extract! person, :first_name, :last_name, :age, :city

Calculating -------------------------------------
              before   240.000  memsize (     0.000  retained)
                         5.000  objects (     0.000  retained)
                         4.000  strings (     0.000  retained)
               after   240.000  memsize (     0.000  retained)
                         5.000  objects (     0.000  retained)
                         4.000  strings (     0.000  retained)

Comparison:
              before:        240 allocated
               after:        240 allocated - same

Filed upstream: rails#598

[moberegger]

Also using [] instead of fetch. It's a bit faster.

ruby 3.4.4 (2025-05-14 revision a38531fd3f) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
                  []     1.582M i/100ms
               fetch     1.627M i/100ms
Calculating -------------------------------------
                  []     26.015M (± 4.2%) i/s   (38.44 ns/i) -    129.730M in   4.999980s
               fetch     21.967M (± 4.2%) i/s   (45.52 ns/i) -    110.641M in   5.047802s

Comparison:
                  []: 26014972.6 i/s
               fetch: 21966990.7 i/s - 1.18x  slower

[Insomniak47]

Is the behaviour identical on missing keys?

[moberegger]

Good question. fetch actually throws if the key doesn't exist, vs returning nil. Not clear if this is the intended behaviour or just happenstance. The coding style for the project seems to prefer fetch. I git blamed back 10+ years to see if there was any reasoning for this, but saw nothing of note before losing interest.

Mixed feelings on this. The current implementation would result in 500 errors if/when this occurs, which is not something I would expect or desire from our tooling. But given my intent here was simply performance - not a behavioural change - I will switch this back to fetch; the overall savings still fall within the margin of error (according to ips) and not worth the risk and drift from the upstream project.

[Insomniak47]

Is the behaviour identical on missing keys?