(In reply to Greg Tatum [:gregtatum] from comment #0) > Here is an example profile taking 2 seconds: https://share.firefox.dev/42jZikd I took a stab at fixing fastText but couldn't make the basic example work because it hasn't been updated to work with modern versions of emscripten, and because I couldn't install the version which was recent at the time fastText was written (emscripten SDK 1.39.12, April 2020). But if anyone wants to try, here's what I think the problem is: During fastText module initialization, there are too many calls which go from C++ through the emscripten binding layer back into C++. If those calls can be made to bypass the emscripten binding layer and stay within wasm, the initialization time could be cut by 50% or more.
Bug 1836974 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Greg Tatum [:gregtatum] from comment #0) > Here is an example profile taking 2 seconds: https://share.firefox.dev/42jZikd I took a stab at fixing fastText but couldn't make the basic example work because it hasn't been updated to work with modern versions of emscripten, and because I couldn't install the version which was recent at the time fastText was written (emscripten SDK 1.39.12, April 2020). But if anyone wants to try, here's what I think the problem is: During fastText module initialization, there are too many calls which go from C++ through the emscripten binding layer back into C++. If those calls can be made to bypass the emscripten binding layer and stay within wasm, the initialization time could be cut by 50% or more. The emscripten bindings are [defined in webassembly/fasttext_wasm.cc](https://github.com/facebookresearch/fastText/blob/0622aad8571861d290b237e83e04e9a07a28839d/webassembly/fasttext_wasm.cc#L185).