Stop paying attention to previousResult in InMemoryCache. #5644
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
benjamn
commented
Dec 2, 2019
Comment on lines
-100
to
-105
| if (c.previousResult) { | ||
| // If a previousResult was provided, assume the caller would prefer | ||
| // to compare the previous data to the new data to determine whether | ||
| // to broadcast, so we should disable caching by returning here, to | ||
| // give maybeBroadcastWatch a chance to do that comparison. | ||
| return; | ||
| } |
There was a problem hiding this comment.
These are the "comments I removed" that I was referring to above. ♻️
benjamn
force-pushed
the
allow-evicting-specific-fields
branch
from
9c33678 to
5f153e8
Compare
benjamn
changed the base branch from
allow-evicting-specific-fields
to
release-3.0
The previousResult option was originally a way to ensure referential identity of structurally equivalent cache results, before the result caching system was introduced in #3394. It worked by returning previousResult whenever it was deeply equal to the new result. The result caching system works a bit differently, and in particular never needs to do a deep comparison of results. However, there were still a few (test) cases where previousResult seemed to have a positive effect, and removing it seemed like a breaking change, so we kept it around. In the meantime, the equality check has continued to waste CPU cycles, and the behavior of previousResult has undermined other improvements, such as freezing cache results (#4514). Even worse, previousResult effectively disabled an optimization that allowed InMemoryCache#broadcastWatches to skip unchanged queries (see comments I removed if curious). This commit restores that optimization. I realized eliminating previousResult might finally be possible while working on PR #5617, which made the result caching system more precise by depending on IDs+fields rather than just IDs. This additional precision seems to have eliminated the few remaining cases where previousResult had any meaningful benefit, as evidenced by the lack of any test changes in this commit... even among the many direct tests of previousResult in __tests__/diffAgainstStore.ts! The removal of previousResult is definitely a breaking change (appropriate for Apollo Client 3.0), because you can still contrive cases where some never-before-seen previousResult object just happens to be deeply equal to the new result. Also, it's fair to say that this removal will strongly discourage disabling the result caching system (which is still possible for diagnostic purposes), since we rely on result caching to get the benefits that previousResult provided.
benjamn
force-pushed
the
ignore-previousResult-when-reading-from-cache
branch
from
f9c6d60 to
8c622bb
Compare
benjamn
added a commit
that referenced
this pull request
Jan 3, 2020
Fixes #5733, which was caused by multiple watches having the same cache key, so none except the first were ever re-broadcast, since the first broadcast had the side effect of marking the later watches as clean, before this.watches.forEach had a chance to visit them. Background: PR #5644 reenabled an important optimization for the InMemoryCache#broadcastWatches method, allowing it to skip watches whose results have not changed. Unfortunately, while this optimization correctly determined whether the result had changed, it did not account for the possibility of multiple distinct consumers of the same result, which can happen (for example) when multiple components use the same query and variables via different useQuery calls. Fortunately, the fix is straightforward (if not exactly obvious): in order to assign distinct consumers different cache keys, it suffices to include the provided watch.callback function in the cache key. A more drastic way to fix #5733 would be to remove the caching of maybeBroadcastWatch entirely, which would not be a huge loss because the underlying cache.diff method is also cached. For now, though, with that backup option in mind, I'd like to preserve this optimization unless it causes any further problems.
benjamn
added a commit
that referenced
this pull request
Jan 3, 2020
Fixes #5733, which was caused by multiple watches having the same cache key, so none except the first were ever re-broadcast, since the first broadcast had the side effect of marking the later watches as clean, before this.watches.forEach had a chance to visit them. Background: PR #5644 reenabled an important optimization for the InMemoryCache#broadcastWatches method, allowing it to skip watches whose results have not changed. Unfortunately, while this optimization correctly determined whether the result had changed, it did not account for the possibility of multiple distinct consumers of the same result, which can happen (for example) when multiple components use the same query and variables via different useQuery calls. Fortunately, the fix is straightforward (if not exactly obvious): in order to assign distinct consumers different cache keys, it suffices to include the provided watch.callback function in the cache key. A more drastic way to fix #5733 would be to remove the caching of maybeBroadcastWatch entirely, which would not be a huge loss because the underlying cache.diff method is also cached. For now, though, with that backup option in mind, I'd like to preserve this optimization unless it causes any further problems.
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.
The
previousResultoption was originally a way to ensure referential identity of structurally equivalent cache results, before the result caching system was introduced in #3394. It worked by returningpreviousResultwhenever it was deeply equal to the new result.The result caching system works a bit differently, and in particular never needs to do a deep comparison of results. However, there were still a few (test) cases where
previousResultseemed to have a positive effect, and removing it seemed like a breaking change, so we kept it around.In the meantime, the equality check has continued to waste CPU cycles, and the behavior of
previousResulthas undermined other improvements, such as freezing cache results (#4514). Even worse,previousResulteffectively disabled an optimization that allowedbroadcastWatchesto skip unchanged queries (see comments I removed if curious). This commit restores that optimization.I realized eliminating
previousResultmight finally be possible while working on PR #5617, which made the result caching system more precise by depending on IDs+fields rather than just IDs. This additional precision seems to have eliminated the few remaining cases wherepreviousResulthadany meaningful benefit, as evidenced by the lack of any test changes in this commit… even among the many direct tests of
previousResultinsrc/cache/inmemory/__tests__/diffAgainstStore.ts!The removal of
previousResultis definitely a breaking change (appropriate for Apollo Client 3.0), because you can still contrive cases where some never-before-seenpreviousResultobject just happens to be deeply equal to the new result. Also, it's fair to say that this removal will strongly discourage disabling the result caching system (which is still possible for diagnostic purposes), since we rely on result caching to get the benefits thatpreviousResultprovided. Despite those modest theoretical drawbacks, it would be a relief to be done withpreviousResult, and I doubt we will find a better opportunity than AC3.