-
Notifications
You must be signed in to change notification settings - Fork 21
Stream legacy blocks straight to legacy without deserialization #250
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
base: main
Are you sure you want to change the base?
Stream legacy blocks straight to legacy without deserialization #250
Conversation
a6db74d to
a3d40e1
Compare
07a7dec to
3a6903d
Compare
f1edca9 to
a2720a2
Compare
|
🤖 Claude Code Review Status: Complete Current Review: This PR optimizes legacy block streaming by avoiding deserialization overhead, which is good for CPU performance. However, there is one significant issue to address:
Positive changes:
The core optimization is sound, but consider the memory/CPU tradeoff for the |
| // NewRawBlockMessage creates a RawBlockMessage by reading all bytes from the reader. | ||
| // The data must be in wire-format block encoding (header + txcount + transactions). | ||
| func NewRawBlockMessage(reader io.Reader) (*RawBlockMessage, error) { | ||
| data, err := io.ReadAll(reader) |
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.
Memory Issue: Loading entire block into RAM
The io.ReadAll() call loads the entire block into memory. For 4GB blocks mentioned in the comments, this causes a 4GB+ memory spike per block request.
Problem:
- Multiple concurrent peer requests could cause severe memory pressure
- This defeats the streaming optimization mentioned in the PR description
Suggestion:
Consider whether the wire protocol supports true streaming without loading the entire payload into memory first, or if this memory tradeoff is acceptable for the CPU performance gain.
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.
The Bitcoin wire protocol message format requires:
[Magic: 4 bytes][Command: 12 bytes][Length: 4 bytes][Checksum: 4 bytes][Payload]
The checksum must be in the header BEFORE the payload. This means you need the entire payload to:
- Calculate its length
- Calculate its SHA256 checksum
We'll revisit this possible improvement later
|



No description provided.