A big.Int value has 32 bytes in size
- 1 byte for a bool
- 8 bytes for a slice pointer (one word)
- 8 bytes for the slice length (one word)
- 8 bytes for the slice capacity (one word)
- 7 padding bytes
The number that it is holding only has 16 bytes, so using a big.Int adds an extra allocation, indirection and triples the memory use.
I propose the type Uint128 to be changed to:
type Uint128 struct { High, Low uint64 }There are libraries in the community that define a Uint128 with its operations. I don't think there is a need for any operations here, so we could have the serialization and deserialization hand-coded here (using the binary package). If we don't want to deal with those operations we could depend on one such library.
For consumers that already have a big.Int we could provide a Uint128FromBig(*big.Int) Uint128 function.
This would be a braking change on the API, but that is ok by the status on the README.
A
big.Intvalue has 32 bytes in sizeThe number that it is holding only has 16 bytes, so using a
big.Intadds an extra allocation, indirection and triples the memory use.I propose the type
Uint128to be changed to:There are libraries in the community that define a
Uint128with its operations. I don't think there is a need for any operations here, so we could have the serialization and deserialization hand-coded here (using the binary package). If we don't want to deal with those operations we could depend on one such library.For consumers that already have a
big.Intwe could provide aUint128FromBig(*big.Int) Uint128function.This would be a braking change on the API, but that is ok by the status on the README.