-
-
Notifications
You must be signed in to change notification settings - Fork 291
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
Refactor sync hashBlocks #4343
Refactor sync hashBlocks #4343
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
didn't we move away from using buffers? not sure though why we did it? |
I think for modules that run in Browser like
Buffer turns out to be better than Uint8Array in some scenarios:
Looking into the |
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.
@tuyennhv we should be very explicit about this function being meant for NodeJS only. And until we don't have browser tests in Lodestar merging this is not safe as it can break everything again.
I think its fine now, because in eth2-light-client demo, we inject buffer using craco https://github.com/ChainSafe/eth2-light-client-demo/blob/master/craco.config.js#L37:L39 |
@dapplion this function is only used in range sync of the BeaconNode, we can make it clear by:
what do you think? |
@tuyennhv Since byteArrayConcat was used only in hashBlocks I've refactored the function to not even need it.
|
Motivation
Using
Buffer.concat
is better than concatenating Uint8Arrays manually both in term of memory and performanceDescription
Buffer.from(Uint8Array.buffer)
gives no memory allocationBuffer.concat