Skip to content
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

Open
Tracked by #56
Jorropo opened this issue Jan 26, 2023 · 1 comment · May be fixed by ipfs/boxo#192
Open
Tracked by #56

valuify blocks.Block #45

Jorropo opened this issue Jan 26, 2023 · 1 comment · May be fixed by ipfs/boxo#192

Comments

@Jorropo
Copy link
Contributor

Jorropo commented Jan 26, 2023

blocks.Block being an interface force at least two allocations per blocks ([]byte + the block.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.

@Jorropo Jorropo changed the title block.Block being an interface force at least two allocations per blocks ([]byte + the block.Block implementation). valuify block.Block Jan 26, 2023
@Jorropo Jorropo self-assigned this Jan 26, 2023
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
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
@Jorropo Jorropo changed the title valuify block.Block valuify blocks.Block Jan 26, 2023
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.
@Jorropo
Copy link
Contributor Author

Jorropo commented Feb 18, 2023

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
@Jorropo Jorropo linked a pull request Mar 3, 2023 that will close this issue
@hacdias hacdias transferred this issue from ipfs/boxo Jun 29, 2023
@ipfs ipfs deleted a comment from welcome bot Jun 29, 2023
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
@Jorropo Jorropo removed their assignment Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: 🏃‍♀️ In Progress
1 participant