RBS scan cache to improve overall performance

[skatkov]

RBS parsing repeatedly searched growing method and attribute arrays, making classes with many declarations quadratic. This replaces those searches with parser-local Hash indexes while leaving the ordered code-object collections unchanged.

The indexes are initialized from existing context members and updated when methods, attributes, or aliases are added. This preserves behavior for rebuilt stores, forward aliases, and legacy instance methods with a nil singleton value.

Five measured runs with 2,000 declarations per workload:

Parser-only workload	Baseline	Optimized	Speedup
RBS methods	0.1610s	0.0353s	4.6x
RBS attributes	0.1108s	0.0253s	4.4x

End-to-end workload	Baseline	Optimized	Change
RBS methods	0.722s	0.587s	-18.7%
RBS attributes	0.630s	0.569s	-9.8%

Benchmark
https://gist.github.com/skatkov/82f89eaf2269286a42a4adf966d2fd12

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[tompng]

I agree that the quadratic cost should be fixed. However, it also happens in the normal RDoc parse path, not just RBS.

It would be simpler to implement the cache in Context itself rather than in each parser. Making context.find_method faster fixes all of them at once, and the parser-side change in this PR reduces to a few lines.

Context already has a hash-based lookup: @methods_hash. It could not be used for find_method as-is because @method_list and @methods_hash could disagree — the main source was the #initialize → ::new rename performed after add_method, which left the hash keyed by the old name. I've just opened #1802 to remove that. Once it is merged, a parse-time lookup can read @methods_hash directly.

Concretely, we could add internal methods like context.find_method_from_hash / context.find_attribute_from_hash, marked # :nodoc:. Two things to keep in mind:

• @methods_hash also holds attributes (for redefinition checks), so the method finder needs an RDoc::Attr check.
• The remaining list/hash divergences (e.g. remove_invisible only removes from @method_list) happen after parsing, so they don't affect parse-time lookups like this PR's, but they are why the public find_method can't simply switch to the hash yet. Longer term, @method_list and @methods_hash should be unified into a single source of truth (same for @constants and @constants_hash), and these internal methods can be removed at that point.

[skatkov]

I will revisit this PR once #1802 will be merged.