Consider using bit-packed vector for storing coordinates

[danpat]

Currently, we're using int32_t to store lat/lon values, and we're capping at 6 decimal places of precision (gives us around 10cm precision at the equator, and better elsewhere)

This means that we have known min/max values, and we're probably not using the entire 32bit space. There's an opportunity here to save a bit of memory.

value	integer value	binary pattern for integer
179.999999	179999999	0000 1010 1011 1010 1001 0100 1111 1111
-179.999999	-179999999	1111 0101 0100 0101 0110 1011 0000 0001
89.999999	89999999	0000 0101 0101 1101 0100 1010 0111 1111
-89.999999	-89999999	1111 1010 1010 0010 1011 0101 1000 0001

So, it looks like we need 28 bits for longitude, 27 bits for latitude, and 1 additional bit for sign. We could save 9% space (1-29/32) for longitude coordinate storage, and 12.5% for latitude storage.

Bit 31 is currently the sign bit. Bits 27/28 to 30 are unused for coordinate data, except that negative numbers are encoded using two's complement representation. We would need special handling for this to maintain the sign bit and proper encoding.

Todo:

• evaluate large-scale memory usage to see if 9% saving here is worthwhile
• measure performance impact of additional bit-packing logic for coordinate access
• do it

/cc @TheMarex @lbud

[daniel-j-h]

except that negative numbers are encoded using two's complement representation.

impl. defined :/ http://eel.is/c++draft/basic.fundamental#7

[github-actions]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.