No performance testing done yet. I'm yet to have done a large Rust project using sodium. The only FRP graphs ran are just the test cases for making sure sodium does the right thing.
I'm doing an alternative Rust version to make up for performance issues I felt in the TypeScript version. Which is a little counter productive. But I also really wanted to tidy up the interface exposed by the Rust version so it more closely matches the TypeScript version as well. And to get rid of all those Gc<> wrappers the end user has to use currently in sodium-rust version 1 and make it more nicer to use.
I'll start using it once I've got the GC issue out of the way. I could try out the algorithm on a fork of the TypeScript version of sodium, I have a large-ish TypeScript project I could try it out on.
When I felt a performance hit one time on a TypeScript. I believe I had about 1000 nodes firing in a single transaction. When I stepped the code, there were switches activating causing rank changes too. I quickly learnt to batch my Stream events into a Stream of a collection of changes, rather than firing each change individually. That got me a bit of a speed boost. But it sill bothered me that a 1000 nodes firing would cause such a slow down.
I mainly fell into Rust for getting into web-assembly. However the debug support for web assembly is not really there yet (In a production ready sense). DWARF is working for source maps, but not for inspection of variables. Hopefully it goes done one day. Not a real big fan of printf() debugging, it hurts my productivity too much.