Open ValarDragon opened 4 months ago
The update introduces a significant enhancement to the MutableTree
structure, specifically within its saveNewNodes
method. By leveraging goroutines, the process of saving nodes now occurs concurrently, leading to improved performance. This approach is complemented by the use of channels for effective communication and error management. Additionally, the update ensures that nodes are properly detached and their keys are recursively assigned, optimizing the process for parallel execution and enhancing overall efficiency and error handling.
File(s) | Summary of Changes |
---|---|
mutable_tree.go |
Introduced goroutines in saveNewNodes for parallel node saving, with channels for communication and error handling. Optimized for parallelization, including recursive key assignment and improved efficiency. |
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Note that this code preserves functionality, as the recursive loop just builds a list of newNodes, and then we just one-by-one serially call SaveNode on it. So we still have the serial SaveNode behavior
We've tested this gave a speedup on IAVL v1 on Osmosis!
I love this conceptually, write nodes to disk as the tree is hashed and node keys are generated in parallel.
I guess one draw back is failing partway through tree traversal - those nodes are now possibly orphaned.
This PR parallelizes to SaveNodes, and figuring out what it is we have to write. ("saveNewNodes").
We can improve this in the future to process eveything but "Set" in another goroutine, and then keep a buffered queue for "Set" that completes asynchronously.
If this is not useful with the IAVL v2 work, can I just put this in the IAVL v1 line?
This PR as is feels like a pretty straightforward improvement, that should give a 7% sync improvement on Osmosis for IAVL v1 today. I don't think theres any tests to add here, I don't see any edge case here thats not covered by existing tests.
Benchmark for 2000 blocks on IAVL v1 on osmosis mainnet for context:![image](https://github.com/cosmos/iavl/assets/6440154/e477931e-1cfb-40d4-905a-c537d22e9a12)
This PR will drop the latency of this from 42 seconds to 24 seconds. However
We should be able to with subsequent work:
Better parallelism would make it: