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
Now when we're importing several PoA headers in single call, every header import starts from the scratch - i.e. we're creating ImportContext, ValidatorsSet and FinalityVotes (see #116 ). But we actually may reuse FinalityVotes from the parent' header import (if parent is imported in the same call) + construct ImportContext and ValidatorsSet after parent is imported (without any additional reads). This will decrease number of redundant storage reads significantly, because relay is now configured to submit 32 headers in single transaction.
The text was updated successfully, but these errors were encountered:
The storage reads are going to be cached anyway (coming from the overlay), so I don't think this optimization is critical. We would for sure minimize the number of host calls though.
It sounds to me like it's a "good first issue" as well, so tagging as such.
Now when we're importing several PoA headers in single call, every header import starts from the scratch - i.e. we're creating
ImportContext
,ValidatorsSet
andFinalityVotes
(see #116 ). But we actually may reuseFinalityVotes
from the parent' header import (if parent is imported in the same call) + constructImportContext
andValidatorsSet
after parent is imported (without any additional reads). This will decrease number of redundant storage reads significantly, because relay is now configured to submit 32 headers in single transaction.The text was updated successfully, but these errors were encountered: