celestiaorg / celestiaorg/rsmt2d

api: revisit GetCell allocations

Open
#232 0 comments 1 reaction 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
169
Forks
87
Avg merge
8h 9m
Merged PRs (30d)
7

Description

The `GetCell` method returns the cell via [allocation of a new slice](https://github.com/celestiaorg/rsmt2d/blob/b54cb5a96cbbf1427bf3d39afca33f84b66a8d42/datasquare.go#L302-L303) and copying desired cell into it. Presumably, this is done for encapsulation reasons. However, the `GetCell` is used in hot paths putting pressure on GC(TODO profiles showing that). So we have a trade-off between foolproof API(prohibiting users from altering the internal slice in rsmt2d) and performance. The proposal is to either:
* Add the new `GetCellUnsafe` method
* Still breaks the perfect encapsulation leaking the internal slice for overwrites
* Change the `GetCell` method to return the subslice stored on the EDS.

Contributor guide

Open the contributing guide

Research direction

Start with GetCell in datasquare.go at lines 302-303 and inspect its hot-path callers. Review the trade-off between returning a copied cell and exposing the stored subslice, then use the referenced GC profiles to compare the proposed API options. Done means an agreed API choice with evidence that allocation pressure is addressed without an unintended encapsulation break.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
performance
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.