Convert block heights to int32. #481
Conversation
|
I was asked in IRC why not just serialize with variable length ints, so I wanted to address that here as well for others that have the question. Using variable length ints for the block heights doesn't make sense in my opinion because they take 5 bytes to represent the most common block range versus only 4 bytes for the fixed size serialization. The variable length int serialization size breaks down as follows: For example, consider the current block chain height which is roughly 369,000. So, how many bytes would it take to serialize each of these heights using varints? 252 bytes for the first 252 block heights, 195,846 bytes for the next 65,282 heights, and 1,518,590 bytes for the next 303,718 heights. Adding that up results in 252 + 195,846 + 1,518,590 = 1,714,688 bytes. Now, consider using a fixed 4-byte serialization for the height: 369,000 * 4 = 1,476,000 bytes. Extending that to the rest of the blocks up to the max int32 from that point would save an additional 2,147,114,647 bytes. Also, that doesn't include the fact that heights are often serialized more than once due to having different indices. As a result, those savings have to be multiplied by every instance a height is stored in an index. |
|
OK |
This commit converts all block height references to int32 instead of int64. The current target block production rate is 10 mins per block which means it will take roughly 40,800 years to reach the maximum height an int32 affords. Even if the target rate were lowered to one block per minute, it would still take roughly another 4,080 years to reach the maximum. In the mean time, there is no reason to use a larger type which results in higher memory and disk space usage. However, for now, in order to avoid having to reserialize a bunch of database information, the heights are still serialized to the database as 8-byte uint64s. This is being mainly being done in preparation for further upcoming infrastructure changes which will use the smaller and more efficient 4-byte serialization in the database as well.
davecgh
force-pushed
the
blockheight_int32
branch
from
ae81f61
to
0280fa0
Compare
This pull request depends on btcsuite/btcutil#56.
This pull request converts all block height references to int32 instead of int64. The current target block production rate is 10 mins per block which means it will take roughly 40,800 years to reach the maximum
height an int32 affords. Even if the target rate were lowered to one block per minute, it would still take roughly another 4,080 years to reach the maximum.
In the mean time, there is no reason to use a larger type which results in higher memory and disk space usage. However, for now, in order to avoid having to reserialize a bunch of database information, the heights are still serialized to the database as 8-byte uint64s.
This is mainly being done in preparation for further upcoming infrastructure changes which will use the smaller and more efficient 4-byte serialization in the database as well.