-
Notifications
You must be signed in to change notification settings - Fork 168
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
Sigverify wraps each PacketBatch with Arc #3035
base: master
Are you sure you want to change the base?
Conversation
@@ -65,7 +65,7 @@ pub struct BankingTracer { | |||
#[cfg_attr( | |||
feature = "frozen-abi", | |||
derive(AbiExample), | |||
frozen_abi(digest = "F5GH1poHbPqipU4DB3MczhSxHZw4o27f3C7QnMVirFci") | |||
frozen_abi(digest = "GxZSv4cLjY97v6UospZnyfKurN6UciYqDvFgZJByP9KW") |
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.
No actual change in serialization because arc itself isnt' serialized, only contents.
@@ -366,17 +366,17 @@ fn recv_send( | |||
|
|||
pub fn recv_packet_batches( |
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.
we do the Arc
wrapping here - this is only called by sigverify stage afaict
@alessandrod would be nice to profile this to know the overhead on the additional Arc-(wrapping/copying) of I think should be relatively minor since:
|
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.
Couple minor comments, but LGTM.
Do we have any existing bencher or anything that will help understand the improvement from not copying? Or any performance data you've collected?
I didn't include these as standard benches since we don't plan to do it; but I can make a few lines changes to compare the Benchmark Results
Description of Changes for BenchmarkNormal benchmark code. Create view using a reference to byte slice: let _ = TransactionView::try_new_unsanitized(black_box(bytes.as_ref())).unwrap(); Copying a byte slice to vec: let _ = TransactionView::try_new_unsanitized(black_box(bytes.to_vec())).unwrap(); and adding impl for impl TransactionData for Vec<u8> {
#[inline]
fn data(&self) -> &[u8] {
&self
}
} |
Results are somewhat surprising to me. I would have naively expected performance improvement to be correlated with size of transactions (e.g. packed transfers improve more than simple transfers). Any idea why that's not the case? |
Small transactions are (now) pretty damn fast. Any overhead from copying (or in this case reaching out to allocator to get Vec) is large in comparison to the parsing speed. When we get to larger transactions, parsing does become fairly expensive so the relative impact of the overhead from allocating/copying is lower. Hadn't stated previously, but we could probably do pretty well with copying data into pre-allocated buffers. |
Problem
Arc<(Vec<PacketBatch>, Option<SigverifyTracerPacketStats>)>
tobanking_trace
/banking_stage
.Arc::clone
the currentmessage
type, the worst-case overhead per packet (assuming only one packet per message is kept) is very largePacketBatch
in anArc
reduces this worst-case overhead considerablySummary of Changes
PacketBatch
in anArc
before sending toBankingStage
Fixes #