Merge upstream metadata without an intermediate filtered hash - #32
Open
OskarEichler wants to merge 1 commit into
Open
Merge upstream metadata without an intermediate filtered hash#32OskarEichler wants to merge 1 commit into
OskarEichler wants to merge 1 commit into
Conversation
Contributor
|
I'll be looking at this soon. Can you provide a more human digestable rationale for what problem this is solving? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
key?:Hash#mergeonly invokes that block for a conflict.nil/false), shallow merge semantics, key order and input ownership.Why / measurement
The current implementation filters the full upstream hash, then merges the filtered hash, and rechecks membership for every nested conflict. The replacement removes that temporary hash and redundant callbacks/lookups.
Ruby 4.0.6 with YJIT, three alternating sequential processes per revision; each process takes the median of five batches of 1,000 merges. Synthetic configurations have two plugin keys and four upstream keys per rule:
This is a metadata-merge microbenchmark, not a claim about end-to-end linter speed.
A standalone benchmark input (run the same code on base and branch):
Verification
bundle exec rake test.bundle exec standardrb libpasses. Full non-correctingrake test standardretains the baselineGemspec/DeprecatedAttributeAssignmentoffense atlint_roller.gemspec:22; I did not run the default auto-correcting task or edit tests.Compatibility and limitations
Breaking changes: none intended for the Hash/YAML configuration API. The result remains a new outer hash, unselected rules are excluded, plugin values win, and nested values retain existing shallow ownership semantics. No dependencies, Ruby requirement or public API are changed here. Arbitrary Hash subclasses overriding core methods, Ruby 2.6/2.7 and non-MRI engines were not executed. Unreleased plugin-comparison and gemspec changes are excluded from the consumer backport.