Allow selectively opting out of cache result canonization. #8188
Conversation
This file contains 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
Although cache result canonization (#7439) is algorithmically efficient (linear time for tree-shaped results), it does have a computational cost for large result trees, so you might want to disable canonization for exceptionally big queries, if you decide the future performance benefits of result canonization are not worth the initial cost. Fortunately, this implementation allows non-canonical results to be exchaged later for canonical results without recomputing the underlying results, but merely by canonizing the previous results. Of course, this reuse happens only when the cache has not been modified in the meantime (the usual result caching/invalidation story, nothing new), in which case the StoreReader does its best to reuse as many subtrees as it can, if it can't reuse the entire result tree.
Previously, queryInfo.diff would be reused as long as the variables hadn't changed, but changes in other options (like canonizeResults) should also trigger recomputation of cache.diff.
benjamn
force-pushed
the
allow-opting-out-of-canonization
branch
from
d43f0c1
to
b63cc02
Compare
benjamn
commented
May 10, 2021
Comment on lines
+144
to
+162
| const other = this.executeSelectionSet.peek(...peekArgs); | ||
|
|
||
| if (other) { | ||
| if (canonizeResults) { | ||
| return { | ||
| ...other, | ||
| // If we previously read this result without canonizing it, we can | ||
| // reuse that result simply by canonizing it now. | ||
| result: this.canon.admit(other.result), | ||
| }; | ||
| } | ||
| // If we previously read this result with canonization enabled, we can | ||
| // return that canonized result as-is. | ||
| return other; | ||
| } | ||
|
|
||
| // Finally, if we didn't find any useful previous results, run the real | ||
| // execSelectionSetImpl method with the given options. | ||
| return this.execSelectionSetImpl(options); |
There was a problem hiding this comment.
This is the clever part, because it means you could disable canonization for a big query fetched during page load (to avoid the cost of canonization), but later trade up to a canonized version of that same result, without redoing much/any of the underlying execSelectionSetImpl work.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Although cache result canonization (#7439) is algorithmically efficient (linear time for tree-shaped results), it does have a computational cost for large result trees, so you might want to disable canonization for exceptionally big queries, if you decide the future performance benefits of result canonization are not worth the initial cost.
Fortunately, this implementation allows non-canonical results to be exchanged later for canonical results without recomputing the underlying results, but merely by canonizing the previous results.
Of course, this reuse happens only when the cache has not been modified in the meantime (the usual result caching/invalidation story, nothing new), in which case the
StoreReaderdoes its best to reuse as many subtrees as it can, when it can't reuse the entire result tree.