-
Notifications
You must be signed in to change notification settings - Fork 11
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
valuify blocks.Block
#45
Comments
4 tasks
Jorropo
changed the title
valuify Jan 26, 2023
block.Block
being an interface force at least two allocations per blocks ([]byte
+ the block.Block
implementation).block.Block
Jorropo
referenced
this issue
in Jorropo/go-libipfs
Jan 26, 2023
The goal is to stop doing two allocations for each block (now it will only allocate the `[]byte` buffer, and pass the `cid.Cid, []byte` pair by decomposed registers or stack). This way of changing does not change the syntax for trivial uses of block.Block, so in theory we will have to update only producers of block.Block, not consumers. Fixes #57
2 tasks
Jorropo
referenced
this issue
in Jorropo/go-libipfs
Jan 26, 2023
The goal is to stop doing two allocations for each block (now it will only allocate the `[]byte` buffer, and pass the `cid.Cid, []byte` pair by decomposed registers or stack). This way of changing does not change the syntax for trivial uses of block.Block, so in theory we will have to update only producers of block.Block, not consumers. Fixes #57
7 tasks
Jorropo
referenced
this issue
in ipfs/boxo
Jan 27, 2023
Will be fine performance wise once #57 is fixed.
Jorropo
referenced
this issue
in ipfs/boxo
Jan 27, 2023
Will be fine performance wise once #57 is fixed.
Jorropo
referenced
this issue
in ipfs/boxo
Feb 3, 2023
Will be fine performance wise once #57 is fixed.
List of breakages I find in our orgs:
|
Jorropo
referenced
this issue
in Jorropo/go-libipfs
Mar 3, 2023
The goal is to stop doing two allocations for each block (now it will only allocate the `[]byte` buffer, and pass the `cid.Cid, []byte` pair by decomposed registers or stack). This way of changing does not change the syntax for trivial uses of block.Block, so in theory we will have to update only producers of block.Block, not consumers. Fixes #57
Closed
Jorropo
added a commit
to ipfs/boxo
that referenced
this issue
Oct 6, 2023
Let's not repeat ipfs/go-block-format#45 interface for struct with one implementation and no value added.
hacdias
pushed a commit
to ipfs/boxo
that referenced
this issue
Oct 9, 2023
Let's not repeat ipfs/go-block-format#45 interface for struct with one implementation and no value added.
hacdias
pushed a commit
to ipfs/kubo
that referenced
this issue
Nov 29, 2023
Let's not repeat ipfs/go-block-format#45 interface for struct with one implementation and no value added. This commit was moved from ipfs/boxo@45c797e
hacdias
pushed a commit
to ipfs/kubo
that referenced
this issue
Nov 29, 2023
Let's not repeat ipfs/go-block-format#45 interface for struct with one implementation and no value added. This commit was moved from ipfs/boxo@45c797e
gammazero
added a commit
that referenced
this issue
Aug 6, 2024
The goal is to stop doing two allocations for each block (now it will only allocate the []byte buffer, and pass the cid.Cid, []byte pair by decomposed registers or stack). This way of changing does not change the syntax for trivial uses of block.Block, so in theory we will have to update only producers of block.Block, not consumers. Fixes #45 Replaces ipfs/boxo#192 Note: This change will cause a failure here: https://github.com/ipfs/go-ipld-format/blob/0f7aff00f72e9dea0d9718bc0972e309ba7c3e8d/format.go#L27
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
blocks.Block
being an interface force at least two allocations per blocks ([]byte
+ theblock.Block
implementation).If this was a value struct or even an type Block []byte (we already know the CID in most cases), we would only allocate the []byte and embed or pass by registers (decomposed stack) the rest.
This is gonna break a lot of stuff depending of how brutal we are.
The text was updated successfully, but these errors were encountered: