-
Notifications
You must be signed in to change notification settings - Fork 38
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
feat(block-producer): borrow instead of cloning txs #544
feat(block-producer): borrow instead of cloning txs #544
Conversation
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.
It seems that this PR introduces even more cloning than before, doesn't it? I found 3 cloning of transaction vector here.
Sort of. We have the following signature now: txs: impl IntoIterator<Item = Borrow<ProvenTransaction>> + Clone and txs.iter().map(AuthenticatedTransaction::raw_proven_transaction), so the clones are clones of the iterator. This is a change from before where we cloned the inner transaction data: txs.iter().map(AuthenticatedTransaction::raw_proven_transaction).cloned().collect() I'm 95% confident this works how I expect it to. If there is a better/simpler way to express this borrow + reusable iterator bound then that would be perfect. |
@Mirko-von-Leipzig this makes sense, thank you! The confusing thing here is that we clone |
Agreed; and that is indeed much clearer. I was searching for a clone + iterator combo but missed the fact that you can specify the underlying iterator within |
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! Thank you!
Blocked by PR #543.
Removes the unnecessary deep cloning of transaction data by utilising
Borrow
. TheTransactionBatch::new
implementation can probably be improved to reduce the amount of iteration occurring, but I'm delaying that until the dust settles on the mempool implementation.Closes #531