-
Notifications
You must be signed in to change notification settings - Fork 38.7k
6% faster, 6% less memory: more tightly pack CCoinMap::value_type #16970
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This change reduces CCoinMap's value_type from 96 bytes to 80 bytes by more tightly packing it's data. This is achieved by these changes: * Refactored prevector so it uses a single byte to determine its size when in direct mode * Reduce CScriptBase from 28 to 27 indirect bytes * align CTxOut to 4 bytes to prevent padding when used as a member in Coin This tighter packing means more data can be stored in the coinsCache before it is full and has to be flushed to disk. In my benchmark, -reindex-chainstate was 6% faster and used 6% less memory. The cache could fit 14% more txo's before it had to resize.
| * CAmount, and 28 for CScript. As a member of Coin, this leaves 4 bytes for | ||
| * Coin's nHeight without the need for any padding. | ||
| */ | ||
| #pragma pack(push, 4) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this break on oldschool 32-bit ARM where int reads are required to be aligned (and I presume this includes 64-bit ints?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's a problem, we are using uint32_t everywhere and align to 4 byte, so it should be fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm? Isn't nValue an 8-bit integer? Or am I misunerstanding what this does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes its 8byte, but I thought it would still be ok because of how it's used in Coin. I guess I've missed something, I really need to set up travis builds... I'll close this for now until I figure out if/how I can do this correctly
unit tests fail https://travis-ci.org/bitcoin/bitcoin/jobs/590073788#L3601 |
This change reduces
CCoinMap::value_typefrom 96 bytes to 80 bytes by more tightly packing it's data. This allows to cache a lot more transactions in the cache. I've achieved this with these changes:prevectorso it uses a single byte to determine its size when in direct modeCScriptBasefrom 28 to 27 indirect bytesCTxOutto 4 bytes to prevent padding when used as a member inCoinThis tighter packing means more data can be stored in the
coinsCachebefore it is full and has to be flushed to disk. In my benchmark,-reindex-chainstatewas 6% faster and used 6% less memory. The cache could fit 14% more txo's before it had to resize.Some numbers:
The graph shows nicely that the cache is able to be used a lot longer before it is full and flushed to the disk:

I've tried this change in combination with #16957 to not cache hash), and then additionally in combination with #16801 :
With all 3 PR's applied, reindex was 14% faster and used 20% less memory