Interestingly, my initial tests of a graph transformation library in #rust and compiled to #wasm hasn't netted an increase in speed.

Granted, this is debug and I haven't done optimizations yet, but It's only doing a simple transformation for now. Regardless, this is still a little surprising.

This goes to show that when working with two different technologies, you should still bench your results before just assuming "faster lang is faster"

@mylesberueda by "this is debug" do you mean using the "debug" cargo profile?

Rust debug builds are way slower than you may realise. You definitely want to never ever test performance on debug builds. Ive had debug-compiled Rust be slower than the same algorithm in Python, a language often held as slow.

@laund The API is way faster (mock api), but the transform library is still near the same, so I'll have to investigate myself.

I know there's still drawbacks with WASM as well; I know for sure it's bad at DOM manipulation rn, and I swear I read something about strings passing the boundary.

The final library that I'm trying to create has to deal with way more graph elements, and a much more invasive transform, so it's good I learn these drawbacks now, before spending a work week on it.

@laund For all I know it's because the function takes `any` on the JS side and `JsValue` on the Rust side before deserializing.

Now that I think about it, that totally could be it. But that's what the experiment is for in the first place 🙂

@mylesberueda yeah thats sounds likely. it might make sense to write directly to the wasm memory from JS, afaik thats the fastest way to pass larger amounts of data. Depending on how the data is created/acquired, it might also make sense to do more in Rust, like constructing a datastructure.

@mylesberueda Well, for Dom manipulation i recommend having a look at https://krausest.github.io/js-framework-benchmark/current.html and selecting vanillajs and wasm-bindgen (to compare the most pure dom manipulation you can, without frameworks getting in the way)

its surprisingly close.

Interactive Results

@laund Oh this is interesting; thanks for the resource!

Part of the scope of the library could potentially deal with canvas manipulation, so this is definitely something I should look into.

Even if the manipulation is slower, the calculations for drawing to canvas could be faster on the Rust/WASM side.

@mylesberueda oh yeah you can definitely do some nice rendering to canvas from Rust. multiple rust graphics packages can compile to wasm and render to a canvas directly, using either WebGL or WebGPU: Bevy is a whole game engine, Macroquad is more for directly drawing. Egui is a immediate mode ui framework which can also draw directly.

https://app.rerun.io is a cool example of a complex application in wasm with rendering

Rerun Viewer

@laund Love the resources, now I'm just furiously typing out notes to try out this upcoming week haha. Thanks for all this!