Thanks for mentioning this other possibility! To be honest, I've discovered this possibility from you. Sadly, it doesn't improve the performance that much. We get the following performance:
- time: 98ms
- throughput: 101Kelem/s
which is way slower than the 2.3ms and 4.18Melem/s we have with our final solution. It's even slower than the `CASE` without the `LEFT JOIN` (which was 39ms and 251Kelem/s).
WebAssembly only supports i32, i64, f32, and f64 for the moment. So you need to allocate the string manually inside the Wasm memory, then pass the pointer of that string to the Wasm function.
I will add an example to showcase that, many people are asking this :-).
Would it be possible to make go functions that wrap string passing, and add them to the go api? Is freeing the memory manually inside the wasm vm something that can be delegated to the vm?
At my work, we have developped `loupe`, a Rust crate that does precisely that, https://github.com/wasmerio/loupe/. I'm the main author of it.
`loupe` provides the `MemoryUsage` trait; It allows to know the size of a value in bytes, recursively. So it traverses most of the types, and its fields or variants as deep as possible. Hopefully, it tracks already visited values so that it doesn't enter an infinite loupe loop.
We are using it inside Wasmer, a WebAssembly runtime.
We don't support that yet, but we are working on it. It's not that easy even if the theory is kind of simple to explain. The implementation in the different backends is mostly the challenge. The Python extension uses the Wasmer runtime (https://github.com/wasmerio/wasmer) which supports 3 backends to generate executable code: Singlepass, Cranelift, and LLVM.
Cranelift is the easiest one to embed, and it brings a great balance between compilation time and execution time. That's the one used in the Python extension right now.
The “import functions” feature is also missing in the PHP extension (https://github.com/wasmerio/php-ext-wasm), but yeah, as I said, we are working on it. It's coming soon!
That's true. However, it allows to integrate your Wasm program to your favorite framework more easily. It's likely to be a small surface of code to review carefully. It's always a balance :-).
It's often for code that is asynchronous that will not return an answer immediately... the function passing is most often used to send a callback for these situations.
A state-machine, generator or coroutine can be used instead of callbacks.
I mostly prefer only having one direction of who-calls-who when combining multiple languages. Though I understand that for a general purpose system like Wasmer it makes sense to support everything, so that users can choose the architecture.
understood, thanks for the explanation - keep up the great work! is there anything external contributors can do to help? :)
I didn't find any issues labelled "good first issue" but I did find a related issue[0]
The best way to help right now is to test it, and report any issues! I've been able to try it on Windows so far for instance.
Also the API isn't complete. We need to be able to grow the memory for instance. We need to understand the community needs to define a roadmap for the community itself.
So he's basically stating that Wasm is better at doing what Java/Shockwave/Flash did.
Thats most likely correct but also beside the point.
The concept of "That one Layer which enables Cross-Platform applications" is just something which has failed, does fail and will fail in the future. Idc if its better at being Java since its still trying to be java.
- time: 98ms - throughput: 101Kelem/s
which is way slower than the 2.3ms and 4.18Melem/s we have with our final solution. It's even slower than the `CASE` without the `LEFT JOIN` (which was 39ms and 251Kelem/s).
Again, thanks for having pointed that out!