The borrow checker is really at its happiest when your ownership and borrow structure is tree-like, so uni-directional references and ownership, because it's mu

The borrow checker is really at its happiest when your ownership and borrow structure is tree-like, so uni-directional references and ownership, because it's much easier to analyse. If the ownership structure that gives the best performance for your problem is not tree-like, you will run into issues with the borrow checker. There are ways to tackle it: you could keep the non-tree-like structure and use reference counting and RefCells to move the borrow checking to runtime, or its possible you could use a less performant but tree-like structure that the borrow checker accepts, but both of these examples would come at a performance cost. It's kinda hard to be more specific because it's heavily dependent on the exact problem.