We completed changes to the get_block_api plugin to speedup performance for the get_block API call. The old implementation used an overly pessimistic mutex locking scheme that severely degraded potential performance under loading. We’ve also added a new API call to fetch a consecutive set of blocks in one disk read operation.
Unfortunately, due to delays related to several hash computations (including one associated with getting the signee key of the block) and conversion of the binary block data to fc::variants and later to json, these API calls are still too slow for the needs of hivemind initial sync.
To overcome this problem, we’re now creating a hived plugin that can directly write the needed data into hivemind’s database during hive reindexing and normal block reception. Most of the data being provided by get_block_api is of no interest to hivemind, so using this API to get the data was unnecessarily wasting CPU, in addition to slowing down hivemind. I expect that using the plugin approach will lead to significant speedup in the initial sync time for hivemind (my guess now is 2x at least) and it should also reduce normal hivemind live-sync write time.
Fuck man you're getting really good at bullshitting laymen that you actually do some work. Congrats on the minor version change :D
How is Dtube going? Long time no see.
Any plans to work on hive and maybe put a proposal up?