Look content types up in a plain Hash instead of an indifferent one

[ericproulx]

PrecomputedContentTypes#content_type_for answers what media type a format maps to, and backed that with a HashWithIndifferentAccess:

def content_type_for(format)
  content_types_indifferent_access[format]
end

Every read ran convert_key before the lookup, because the callers genuinely disagree on spelling — a format negotiated from a path extension, a ?format= or an Accept header arrives as a String, while the API's declared format and the value stashed in api.format are Symbols.

Both spellings can live in the same Hash instead. It is built once per middleware and never written again, so that conversion is work with only one possible answer.

Measurements

Same-process A/B on the lookup:

	HWIA	plain Hash
[:json]	42.3 ns	25.5 ns	1.66x
['json']	38.8 ns	33.7 ns	1.15x

content_type_for runs twice per request — once to negotiate the format, once to set the response content type — and three times when the path carries a format extension (measured by instrumenting the method).

That is about 34 ns per request, roughly 0.6% of a minimal one. End to end this is below what the harness can resolve — repeated runs straddle zero — so no end-to-end figure is claimed. Allocation counts are unchanged: convert_key used Symbol#name, which allocates nothing.

Equivalence

Keys arrive as Symbols — DSL::RequestResponse#content_type calls key.to_sym, and ContentTypes::DEFAULTS are Symbols — but the key is stored as it came as well, so a middleware constructed directly with String keys still answers to either spelling, exactly as the indifferent hash did.

Checked against HashWithIndifferentAccess over the default content types plus unknown, nil and empty keys (16 probes, identical answers), and over a string-keyed hash looked up both ways:

equivalent on 16 probe keys (incl. unknown, nil, empty)
string-keyed: symbol lookup true, string lookup true

Suite green (2652), RuboCop clean.

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run

[dblock]

This feels like an over-optimization but ok.