celestiaorg / celestiaorg/rsmt2d
api: revisit GetCell allocations
- 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
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