Speed up lookup of possible types for Fragments #4506
Merged
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.
Really this is just a readability improvement, but there's a nice perf side effect, too :)
This change speeds up
rake bench:profile_large_result
benchmark by about 1.8%.Baseline (master at cbdae76)
After this change:
This logic used to be more complicated (
t.metadata[:type_class] == owner_type
), but has since been simplified to doing a search for an exact-match (t == owner_type
).graphql-ruby/lib/graphql/execution/interpreter/runtime.rb
Lines 83 to 89 in aec347f
include?
can do this more expressively thaneach
+break
, and has the added benefit of being way faster (since it can run the loop body in C code, rather than needing to call into a Ruby block). Here's a dumb little synthetic benchmark to demonstrate that:Benchmark