You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement the contract deduplication optimization, which avoid applying many times the same contract to a field value. It seems that applying the same contract in different places (say both the framework code consuming a configuration and the configuration) is something that happens in practice, and can lead to many duplicate contracts. This is also the case for arrays lazy contracts, but we left this work for a separate issue.
We already introduced the machinery to be able to compute approximate contract equality (cf #763#766). We were just waiting for a concrete sign that this optimization:
Is needed
Is efficient
#1622 provided us with a codebase to test 2., and where 1. seems to be verified.
This optimization requires that contracts are idempotent, or it could change the meaning of programs, but it's a reasonable assumption to make - even for user-defined contract. We just need to make it very clear in the documentation.
The text was updated successfully, but these errors were encountered:
Implement the contract deduplication optimization, which avoid applying many times the same contract to a field value. It seems that applying the same contract in different places (say both the framework code consuming a configuration and the configuration) is something that happens in practice, and can lead to many duplicate contracts. This is also the case for arrays lazy contracts, but we left this work for a separate issue.
We already introduced the machinery to be able to compute approximate contract equality (cf #763 #766). We were just waiting for a concrete sign that this optimization:
#1622 provided us with a codebase to test 2., and where 1. seems to be verified.
This optimization requires that contracts are idempotent, or it could change the meaning of programs, but it's a reasonable assumption to make - even for user-defined contract. We just need to make it very clear in the documentation.
The text was updated successfully, but these errors were encountered: