Hywan

How different is it from the semantic Web (schema, RDF, OWL…)? Instead of reinventing something, why not using a well established technology that can also be beneficial for other usages?

In this article, I illustrate how Data-oriented Design helped to remove annoying memory pressure and lock contention in multiple sorters used in the Matrix Rust SDK. It has improved the execution by 98.7% (53ms to 676µs) and the throughput by 7718.5% (from 18K elem/s to 1.4M elem/s)! I will talk about how the different memories work, how we want to make the CPU caches happy, and how we can workaround locks when they are a performance bottleneck.

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).

Again, thanks for having pointed that out!

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 :-).

The wasmer-c-api lands in https://github.com/wasmerio/wasmer/tree/master/lib/c-api, with the documentation being accessible at https://wasmerio.github.io/wasmer/crates/wasmer_c_api/index.... :-).

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.

I recommend this excellent reading, https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la.... It clarifies what “safe” means in this context.

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.

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 :-).

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!

No, it's not :-), see https://words.steveklabnik.com/is-webassembly-the-return-of-...