-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
Use bytes representation for Certificate::aggregate_signature #9697
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
@@ -605,7 +606,7 @@ impl Certificate { | |||
|
|||
Ok(Certificate { | |||
header, | |||
aggregated_signature, | |||
aggregated_signature: AggregateSignatureBytes::from(&aggregated_signature), |
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 might be overkill for this problem, but we could also use the Cached object solution you proposed, @benr-ml, in order to avoid that signatures are deserialised even if they are created here and not read from disk.
## Description Profiling has shown that validators spend a significant amount of CPU resources deserialising the `aggregate_signature` field in NW's `Certificate` object when read from disk. This is because signatures by default are stored as compressed points, so deserialisation needs to decompress points which is a non-trivial computation. However, in most cases the signature does not need to be verified, and in these cases the binary representation suffices. This PR replaces the `aggregate_signature` field in NW's `Certificate` object with its `AsBytes` representation, and the signature is only decompressed when the signature actually have to be verified. According to recently produced perf flame graphs, this could save ~2% CPU usage for validators. ## Test Plan Unit tests. ### Type of Change (Check all that apply) - [ ] user-visible impact - [ ] breaking change for a client SDKs - [ ] breaking change for FNs (FN binary must upgrade) - [X] breaking change for validators or node operators (must upgrade binaries) - [ ] breaking change for on-chain data layout - [X] necessitate either a data wipe or data migration
## Description Profiling has shown that validators spend a significant amount of CPU resources deserialising the `aggregate_signature` field in NW's `Certificate` object when read from disk. This is because signatures by default are stored as compressed points, so deserialisation needs to decompress points which is a non-trivial computation. However, in most cases the signature does not need to be verified, and in these cases the binary representation suffices. This PR replaces the `aggregate_signature` field in NW's `Certificate` object with its `AsBytes` representation, and the signature is only decompressed when the signature actually have to be verified. According to recently produced perf flame graphs, this could save ~2% CPU usage for validators. ## Test Plan Unit tests. ### Type of Change (Check all that apply) - [ ] user-visible impact - [ ] breaking change for a client SDKs - [ ] breaking change for FNs (FN binary must upgrade) - [X] breaking change for validators or node operators (must upgrade binaries) - [ ] breaking change for on-chain data layout - [X] necessitate either a data wipe or data migration
Description
Profiling has shown that validators spend a significant amount of CPU resources deserialising the
aggregate_signature
field in NW'sCertificate
object when read from disk. This is because signatures by default are stored as compressed points, so deserialisation needs to decompress points which is a non-trivial computation. However, in most cases the signature does not need to be verified, and in these cases the binary representation suffices.This PR replaces the
aggregate_signature
field in NW'sCertificate
object with itsAsBytes
representation, and the signature is only decompressed when the signature actually have to be verified. According to recently produced perf flame graphs, this could save ~2% CPU usage for validators.Test Plan
Unit tests.
Type of Change (Check all that apply)