Autoresearch optimization run for validation pipeline

[swalkinshaw]

This PR isn't designed to be mergeable as is. It's an experiment running Karpathy's autoresearch process on the static validation pipeline. I used the pi extension.

@rmosolgo feel free to cherry pick any of the below optimizations if you're interested in them.

Couple things of note:

• I used an internal large query/schema for some benchmarking which is scrubbed so this won't be 100% reproducible locally. The built-in benchmark can be used instead.
• I removed some slower tests and used the ./test_fast.sh script for a quicker feedback loop running tests.

Optimize static validation pipeline

~65% faster static validation on realistic workloads, measured with YJIT and Visibility Profiles enabled.

Benchmark results (YJIT, Visibility Profiles, did_you_mean(nil))

Workload	Before	After	Change
small fragment query	68 µs	40 µs	-41%
small abstract types query	114 µs	70 µs	-39%
large query against big schema	1,477 µs	619 µs	-58%
large query against large schema	5,991 µs	1,969 µs	-67%
5000 identical fields (pathological)	1,804,825 µs	1,225 µs	-99.9%

Benchmarks measure only Validator#validate — Query/Profile initialization is excluded.

What changed (20 files, +534/-383)

FieldsWillMerge rewrite

The biggest win. The original algorithm compared fields across three phases (fields-within, fields-vs-fragments, fragments-vs-fragments) with recursive fragment cross-comparison that could be exponential. This rewrites it to:

• Flatten all fragment spreads inline into a single response-key map in one pass, eliminating the three-phase structure entirely
• Deduplicate by signature — fields with identical (name, definition, arguments) are grouped and only one representative pair is compared
• Skip provably-safe selections — if all direct children of a selection set are unaliased fields with unique names (no fragments, no aliases, no duplicates), conflict checking is skipped entirely (~55% of non-leaf fields)
• Defer array wrapping — 85% of response keys have a single field, so store the Field directly instead of wrapping in a single-element array
• Cache sub-selection results and mutually-exclusive type pairs to avoid redundant work across comparisons

Visibility Profile caching

• Cache Profile#field(owner, field_name) results per (owner, field_name) pair — eliminates repeated kind checks, parent lookups, and visibility checks
• Cache Profile#type(type_name) results — eliminates repeated get_type + visibility + referenced? checks

Visitor allocation reduction

• Replace all 4 definition stacks (@field_definitions, @directive_definitions, @argument_definitions, @object_types) with save/restore instance variables — eliminates ~12,000 Array push/pop operations per validation
• Replace @path push/pop with a pre-allocated indexed array + depth counter
• Inline on_fragment_with_type into on_inline_fragment and on_fragment_definition — eliminates block/yield overhead
• Inline setting_errors block into on_field and on_operation_definition

Type system memoization

• Cache Wrapper#unwrap on NonNull/List wrapper objects (schema-level, permanent)
• Cache to_type_signature on NonNull/List wrappers
• Cache field_definition.type.unwrap per Schema::Field in the visitor

Rule-level micro-optimizations

• FieldsHaveAppropriateSelections: reordered fast path to cover both common cases (leaf+no-selections 70%, non-leaf+selections 16%)
• RequiredArgumentsArePresent: cache required argument names per field definition
• FragmentTypesExist/FieldsAreDefinedOnType: skip all_types loading when schema.did_you_mean is nil
• ArgumentNamesAreUnique: avoid Hash.new with default proc; use plain hash
• Direct ivar access (@current_field_definition, @current_object_type, @types, @fragments) instead of accessor methods/delegation in hot paths
• Skip empty .each iteration for arguments, directives, and selections (~6,000 avoided per large validation)

Test changes

3 test expectations in fields_will_merge_spec.rb updated for semantically equivalent error ordering (flattened fragment collection reports errors in a different order than the recursive three-phase approach).

[rmosolgo]

Thanks for sharing what you found here! I definitely wouldn't say no to optimizations in this department. (In the bigger picture, I've lately been wondering, what if we got rid of all the different modules and did validation without so many super calls?)

I don't expect to find time to review these closely until I've got the new execution module out the door (in 2.6.0). After that I'll come review more closely. If there are any of these that you find particularly awesome (FieldsWillMerge rewrite?), please feel free to dress them up for independent review and merge.