Box NewTaskPayload to reduce size greatly #2881
Merged
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.
Problem
NewTaskPayload
is large (more than 200 bytes) due to its direct inclusion ofExecuteTimings
. In turn, this causes large mem writes/reads around crossbeam channel even forNewTaskPayload::Task
.Note that this is particularly problematic for block production mode (senders are multi-threaded whereas block verification is currently single-threaded) because those writes are inside crossbeam channel's linearization point, creating a source of contention.
Summary of Changes
Box the rare variant, which only occurs once per bank, benefiting the other variant channel transmission (99.9% of time). Overall, extra indirection for access and mem alloc/dealloc for the
NewTaskPayload::OpenSubchannel
variant pays off.before
after
maybe 1-2% gain.
Extracted from: #2325