Add new direct index type

[pmconrad]

Added a secondary index that allows O(1) access to objects based on their ID. Mostly useful for accounts and assets.

Speeds up replay by 25% in my tests. :-)

[oxarbitrage]

looks good to me, i didn't made speed comparison but replayed fully. all test cases passing. nice work.

[abitmore]

Looks good at a glance.

• better also use this new index for account_statistics_object, asset_dynamic_data_object and etc
• hard-coded chunk sizes are fine so far, perhaps can change them to configurable in the future
• test cases?
  • new hole over several chunks (in case when chunk size is too small, although perhaps we won't use it this way)

[pmconrad]

better also use this new index for account_statistics_object, asset_dynamic_data_object and etc

These are currently using simple_index, which is already vector-backed.

hard-coded chunk sizes are fine so far, perhaps can change them to configurable in the future

Agree. Chunk size is a minor optimization factor anyway. Need to find a balance between number of chunks and wasted memory due to chunk remaining almost empty.

new hole over several chunks (in case when chunk size is too small, although perhaps we won't use it this way)

This ensures that a hole cannot span several chunks:

FC_ASSERT( (1ULL << chunkbits) > MAX_HOLE, "Small chunkbits is inefficient." );

Will add a unit test for some basics.

[abitmore]

Sorry I overlooked those. I agree that chunk size is a minor optimization factor, since 1M items per chunk means 8MB of RAM which is not big.

[abitmore]

By the way, I think it's possible to optimize account_balance index in a similar way, specifically, for the get_balance(account_id,asset_id) function and a part of adjust_balance() function which are used heavily (#1083 is related but not exactly the same thing). Also #1100 is related.

[oxarbitrage]

I think this looks good, account_balance index if applicable can be discussed and done in a new issue.

[pmconrad]

Already working on account_balance :-)

[pmconrad]

Done. Replay of 32M blocks now takes only a little more than one hour.
@oxarbitrage @abitmore please re-review.

[pmconrad]

Made snapshot comparison with base.

[oxarbitrage]

thank you for confirming with snapshot, test cases all working, code looks good. great addition.

[pmconrad]

Thanks!