Open jplatte opened 5 years ago
This could actually save more space than one would initially expect, because it leaves one byte free for booleans or enum tags (think Option
) without exceeding the required memory alignment of 8
. This would therefore reduce the required memory for Vec<Option<Int>>
by half for example.
But I agree that this has much potential to slow things down and should definitely be benchmarked.
(Also it needs to be considered if the alignment should still be 8 or 1 instead, since it probably needs to be copied to a register anyways)
We theoretically have 54 bits of information in
Int
and 53 bits inUInt
. Because it is much simpler to just wrap an existing numeric type, we currently use 8 bytes (64 bits) to store this data, even though 7 bytes (56 bits) would be sufficient. Implementing 7-byte storage would certainly complicate the code quite a bit and potentially affect performance negatively. I could imagine developing it out under a feature flag though. If we have benchmarks until then (#4), that would be very useful.