[Merged by Bors] - Use THC for state.inactivity_scores
#2504
+52
−43
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
paulhauner
added
ready-for-review
|
@realbigsean I've requested your review since Michael is on leave and this is blocking a |
realbigsean
approved these changes
Aug 9, 2021
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Aug 9, 2021
## Issue Addressed - Resolves #2502 ## Proposed Changes Adds tree-hash caching (THC 🍁) for `state.inactivity_scores`, as per #2502. Since the `inactivity_scores` field is introduced during Altair, the cache must be optional (i.e., not present pre-Altair). The mechanism for optional caches was already implemented via the `ParticipationTreeHashCache`, albeit not quite generically enough. To this end, I made the `ParticipationTreeHashCache` more generic and renamed it to `OptionalTreeHashCache`. This made the code a little more verbose around the previous/current epoch participation fields, but overall less verbose when the needs of `inactivity_scores` are considered. All changes to `ParticipationTreeHashCache` should be *non-substantial*. ## Additional Info NA
paulhauner
added
ready-for-merge
|
Pull request successfully merged into unstable. Build succeeded: |
bors
bot
changed the title
state.inactivity_scoresstate.inactivity_scores
pawanjay176
pushed a commit
to pawanjay176/lighthouse
that referenced
this pull request
Aug 27, 2021
## Issue Addressed - Resolves sigp#2502 ## Proposed Changes Adds tree-hash caching (THC 🍁) for `state.inactivity_scores`, as per sigp#2502. Since the `inactivity_scores` field is introduced during Altair, the cache must be optional (i.e., not present pre-Altair). The mechanism for optional caches was already implemented via the `ParticipationTreeHashCache`, albeit not quite generically enough. To this end, I made the `ParticipationTreeHashCache` more generic and renamed it to `OptionalTreeHashCache`. This made the code a little more verbose around the previous/current epoch participation fields, but overall less verbose when the needs of `inactivity_scores` are considered. All changes to `ParticipationTreeHashCache` should be *non-substantial*. ## Additional Info NA
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.
Issue Addressed
inactivity_scores#2502Proposed Changes
Adds tree-hash caching (THC 🍁) for
state.inactivity_scores, as per #2502.Since the
inactivity_scoresfield is introduced during Altair, the cache must be optional (i.e., not present pre-Altair). The mechanism for optional caches was already implemented via theParticipationTreeHashCache, albeit not quite generically enough to suit this use-case. To this end, I made theParticipationTreeHashCachemore generic and renamed it toOptionalTreeHashCache. This made the code a little more verbose around the previous/current epoch participation fields, but overall less verbose when the needs ofinactivity_scoresare considered.All changes to
ParticipationTreeHashCacheshould be non-substantial.Additional Info
NA