Closed zolstein closed 1 month ago
The actual implementation of Decimal
type is already your suggestion, I'll update the README to match it. As for overflow
, agree that it can be removed and checked by bigint != nil
instead. I'll craft a fix for it. Thanks
The Decimal type is 48 bytes on a 64-bit machine. Even though this is not "large" per se, it seems likely that users would construct large slices of Decimal values, so it's worth trying to reduce the size to pack more values into less memory. There are two relatively easy ways to do this:
First, you can reorder the Decimal fields from this:
to this:
Putting
neg
andprec
together after thecoef
reduces the padding used for alignment, saving 8 bytes.Second, unless I'm missing something, you could refactor
bint
to remove the overflow bool. It looks like you could implicitly infer thatoverflow == (bigint != nil)
. This saves an additional 8 bytes, since Go pads the boolean to makebint
a multiple of 8 bytes. Unlike Decimal, in this case there's no way to reorder the fields to reduce the size.(You could alternately reduce the size by removing
bint
, rolling the fields intoDecimal
, and placingoverflow
alongsideneg
andprec
, but doing this loses the encapsulation ofbint
and requires a larger refactor than just replacing all instances ofoverflow
withbint != nil
.)