perf: Parallelize saveNewNodes' DB writes with figuring out "what to write" #889
Conversation
WalkthroughThe update introduces a significant enhancement to the Changes
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? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| // TODO: Come back and figure out how to better parallelize this code. | ||
| func (tree *MutableTree) saveNewNodes(version int64) error { | ||
| nonce := uint32(0) | ||
| newNodes := make([]*Node, 0) | ||
| var recursiveAssignKey func(*Node) ([]byte, error) | ||
| recursiveAssignKey = func(node *Node) ([]byte, error) { | ||
|
|
||
| nodeChan := make(chan *Node, 64) // Buffered channel to avoid blocking. | ||
| doneChan := make(chan error, 1) // Channel to signal completion and return any errors. | ||
|
|
||
| // Start a goroutine to save nodes. | ||
| go func() { | ||
| var err error | ||
| for node := range nodeChan { | ||
| if saveErr := tree.ndb.SaveNode(node); saveErr != nil { | ||
| err = saveErr | ||
| break | ||
| } | ||
| node.leftNode, node.rightNode = nil, nil // Detach children after saving. | ||
| } | ||
| doneChan <- err // Send any error encountered or nil if none. | ||
| }() | ||
|
|
||
| var recursiveAssignKey func(*Node) []byte | ||
| recursiveAssignKey = func(node *Node) []byte { | ||
| if node.nodeKey != nil { | ||
| if node.nodeKey.nonce != 0 { | ||
| return node.nodeKey.GetKey(), nil | ||
| return node.nodeKey.GetKey() | ||
| } | ||
| return node.hash, nil | ||
| return node.hash | ||
| } | ||
| nonce++ | ||
| node.nodeKey = &NodeKey{ | ||
| version: version, | ||
| nonce: nonce, | ||
| nonce: nonce, // Example nonce calculation; adjust as needed. | ||
| } | ||
|
|
||
| var err error | ||
| // the inner nodes should have two children. | ||
| // Assign keys recursively to child nodes. (Two children are guaranteed) | ||
| if node.subtreeHeight > 0 { | ||
| node.leftNodeKey, err = recursiveAssignKey(node.leftNode) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
| node.rightNodeKey, err = recursiveAssignKey(node.rightNode) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
| node.leftNodeKey = recursiveAssignKey(node.leftNode) | ||
| node.rightNodeKey = recursiveAssignKey(node.rightNode) | ||
| } | ||
|
|
||
| node._hash(version) | ||
| newNodes = append(newNodes, node) | ||
| node._hash(version) // Assuming this hashes the node. | ||
| nodeChan <- node // Send node to be saved. | ||
|
|
||
| return node.nodeKey.GetKey(), nil | ||
| return node.nodeKey.GetKey() | ||
| } | ||
|
|
||
| if _, err := recursiveAssignKey(tree.root); err != nil { | ||
| recursiveAssignKey(tree.root) | ||
| close(nodeChan) // Close the channel on completion. | ||
| if err := <-doneChan; err != nil { // Wait for the saving goroutine to finish. |
There was a problem hiding this comment.
The parallelization of the saveNewNodes function introduces concurrency into the node saving process, which is a significant change aimed at improving performance. However, there are several areas that need attention:
-
Error Handling: The current implementation stops processing new nodes as soon as an error occurs (lines 1042-1045). This approach might leave some nodes unsaved without any attempt to save them. Consider whether it's acceptable to stop immediately or if it would be better to attempt saving all nodes and collect all errors.
-
Detaching Children: Detaching children after saving (line 1046) is done within the goroutine. Ensure that this operation does not introduce any race conditions or inconsistencies, especially since the parent node's references to these children are cleared.
-
Nonce Calculation: The nonce calculation (line 1062) seems to be a placeholder (
nonce++;). Ensure that the nonce calculation logic is correctly implemented and serves its intended purpose. If the nonce is meant to ensure uniqueness or order, verify that this incrementation strategy is sufficient and safe under concurrent conditions. -
Recursive Key Assignment: The recursive assignment of keys to child nodes (lines 1051-1074) is a critical operation. It's important to ensure that this recursion does not introduce any performance bottlenecks or stack overflow issues for trees with significant depth. Additionally, verify that the operation of assigning keys and subsequently hashing nodes (line 1071) is correct and does not lead to any unintended side effects.
-
Channel and Goroutine Management: The use of a buffered channel (line 1035) and a single goroutine (lines 1038-1049) for saving nodes is a straightforward approach to parallelization. However, consider the buffer size of the channel and whether it's adequately sized for the expected workload. Also, ensure that the goroutine's error handling and channel closing logic (lines 1077-1078) are robust and won't lead to goroutine leaks or panic due to double closing channels.
-
Concurrency and Data Races: Given the introduction of concurrency, it's crucial to ensure that there are no data races, especially concerning the access and modification of node properties. Use tools like the Go race detector to verify that the implementation is safe.
Overall, while the parallelization effort is commendable for its potential to improve performance, careful consideration must be given to error handling, concurrency issues, and the correctness of the implementation.
Consider reviewing the error handling strategy, ensuring the safety of detaching children, verifying the nonce calculation logic, assessing the performance and correctness of recursive key assignment, and ensuring robust channel and goroutine management to prevent leaks or panics.
|
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 |
ValarDragon
changed the title
|
We've tested this gave a speedup on IAVL v1 on Osmosis! |
| recursiveAssignKey = func(node *Node) ([]byte, error) { | ||
|
|
||
| nodeChan := make(chan *Node, 64) // Buffered channel to avoid blocking. | ||
| doneChan := make(chan error, 1) // Channel to signal completion and return any errors. |
There was a problem hiding this comment.
There is some overhead with creating channels and goroutine, although likely not so big, it might be better to couple channel and goroutine creation with the lifecycle of MutableTree instead of saveNewNodes.
Since I don't know off hand how much overhead that actually is maybe it's fine as-is too.
|
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. |
| } | ||
| nonce++ | ||
| node.nodeKey = &NodeKey{ | ||
| version: version, | ||
| nonce: nonce, | ||
| nonce: nonce, // Example nonce calculation; adjust as needed. |
There was a problem hiding this comment.
just realized the original codebase is wrong, not a bug but just a performance issue.
newNodes = append(newNodes, node) should come after this line, the main idea of newNodes slice is to save the node in a sorted manner by the nodekey (here the nonce) to reduce the compaction.
Just worried we can't assume this sorted manner after refactoring ...
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:
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: