I updated the vanilla.js script and README to clarify that the key and value sizes are in bytes.
I haven't tried calling into WebAssembly so I don't know. Perhaps the bridging cost would be similar or slightly better (or who knows, worse)? Does WASM have SIMD? Do you know of any areas where WASM would outdo the current Javascript implementation?
For times like these, I wish server-side Javascript itself had SIMD, and access to CPU builtins, such as popcount etc.
Great hash table by the way!
I hacked up a WAT file with this inside a function body and compiled it with wat2wasm --enable-simd
(local $2 v128)
(set_local $2
(i8x16.splat (i32.const 8))
)
As soon as you can imagine something that would "better work in C" it's reasonable to expect that Wasm will have an edge vs. Javascript. Javascript does eventually get JIT-ed etc, but with wasm it's effectively "just the code" from the start -- conceptually, Wasm code doesn't have to contain any checks to "fall back" to some slower implementation, once it's processed.
Here's one of the "minimal" examples of calling the C function which is compiled to the WebAssembly: https://medium.freecodecamp.org/get-started-with-webassembly...
Note the resulting native assembly code in the picture on the right there. It's that minimal. I don't know how big the costs JavaScript to that are... But seeing how beautifully you've measured for your project, I'm quite sure you're more than suited to evaluate that too, and to measure the currently minimal costs. And as there is a lot of interest in these topics, if you demonstrate the obvious weakness there's a chance it could be fixed?
It seems that the string has to be copied every time a call from JavaScript to Wasm is made (there stringToUTF8):
https://blog.teamemo.com/behind-teamemo-using-a-c-library-fr...