-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache results of static types migration and entitlements migration #3396
Conversation
Cadence Benchstat comparisonThis branch with compared with the base branch onflow:master commit bf9965d Collapsed results for better readability
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! My only concern/question is what the performance would be for converting the static-type to bytes (encoding) vs creating a new static type. I guess we can only find out by running the actual migration with it. So good idea to have behind a flag.
Yeah, that's a good point! I think the encoding is fairly similar to the type ID construction (in orders of magnitude), but slightly more expensive computation and memory. I can imagine that for many simple cases in the static type migration the overhead of the caching might be larger than just running the migration. Though for the entitlements migration the caching will likely be worth it. I'll put the two caches behind two separate flags. |
Work towards #3297
Description
In #3375 we removed the broken caching of results of the static types migration and entitlements migration.
Bring back the caching, but use the encoding of the static type instead of the type ID. The encoding of a static type isn't ambiguous or lacking any details compared to the type ID. I double checked that legacy / pre-1.0 information in static types, like the legacy restricted type in an intersection type (previously restriction type), is not only decoded properly for the migration, but also encoded again with the legacy information (which isn't the case for type IDs).
Disable the caching by default, so the default behaviour is always correct. In flow-go, this feature will be enabled through a flag (again, off by default).
I tested this approach in flow-go, and a run with caching always produces the same new state commitment as a non-caching run.
master
branchFiles changed
in the Github PR explorer