ruby-grape / grape / 33557906942

97%

master: 97%

Pull #2881

github

Decide whether a request has a body before building a Rack::Request

`Formatter#read_body_input` opened with

    input = rack_request.body # reads RACK_INPUT
    return if input.nil?
    return unless read_body_input?

so every request built a `Rack::Request` to reach `rack.input`, and then
`read_body_input?` returned false for anything that is not a POST, PUT, PATCH
or DELETE. On the GET, HEAD and OPTIONS majority the object was constructed,
asked for one env key, and discarded.

`read_body_input?` opened with four `Rack::Request` predicates —
`post? || put? || patch? || delete?` — each of which is a comparison against
`env['REQUEST_METHOD']`. Reading that key directly answers the same question
without the object, and it is the first thing the method needs to know.

Test the method off the env, and fetch the input only once the answer is yes.
A body-carrying request builds the `Rack::Request` exactly as before, for the
`form_data?` / `parseable_data?` / `content_length` checks that genuinely need
it; everything else never touches one.

Counted over 20 GETs, the formatter's copy is gone: 20 objects of the
`Rack::Request` family are created rather than 40, the survivor being the
`Grape::Request` the endpoint builds for itself.

End to end that is 166,376 -> 168,173 req/s on a bare JSON GET (+1.1%) and
257,731 -> 261,704 on a static route (+1.5%) — median of 9 runs interleaved
with master's, Ruby 4.0.5 with YJIT — with one fewer object per request.

The reordering is behaviour-preserving. Nothing between the two guards depends
on the input having been read, and `read_body_input?` consults only the request
method, the content type and the content length — never the body.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

1237 of 1332 branches covered (92.87%)

Branch coverage included in aggregate %.

4 of 4 new or added lines in 1 file covered. (100.0%)

3915 of 3983 relevant lines covered (98.29%)

27233.31 hits per line