It is best to use an in-browser profiler to get a feeling of where the hotspots are, and perhaps if you have a native build of the application, use a native profiler on that one, and compare the profiling data between the two. There are still cases in Emscripten runtime where things can go down a performance cliff even though asm.js/Wasm performance itself is very fast, so perhaps a profiler can highlight a some type of performance hotspot that is unexpected.
In general we do see people sometimes having a bias against "oh it's the web/it's JS so of course it's going to be slow", and often the people who say this do not have first hand experience. One way to go around this is to use the new technology name WebAssembly as a way to separate from JavaScript itself, which does not have the same kind of preconception attached to it. 2017-02-18 18:44 GMT-08:00 Boris Sergeev <bserg...@gmail.com>: > Hi to all Emscripters! > ;-) > I am looking for some performance tests comparing manually optimized > JavaScript code vs. emscripted C++ vs. native C++. > > Some people in my company are dismissing Emscripten as too slow and I want > to identified areas where it indeed is and where it is as fast as native. > > Some time ago, I found somebody's simple C++ code generating Pi to any > number of digits. This code doesn't have a lot of data, but does a lot of > number crunching on some limited data. To my surprise, emscripted code > showed the same performance, within the error of measurement, as the native > code (built on different platforms with different compilers). > Then, while working on a multi-platform CAD application, which is built > for both desktop platforms and Web, I've observed emscripted code being > 3...5 times slower than the native code, when operating on models taking up > to 1 GB of memory. I used Chrome profiler and was pleased to see that > copying JS Typed Arrays to Emscripten heap was relatively fast--this code > took less than a second for copying(?) hundreds of megabytes of Uint8Array: > ``` > var length = javascriptArray.length; > var geometry = Module._malloc(length); > var emscrHeap = new Uint8Array(Module.HEAPU8.buffer, geometry, length); > emscrHeap.set(new Uint8Array(javascriptArray.buffer)); > ``` > But the, originally C++ and then emscripted, code performing geometry > manipulations on these large models is several times slower than native. > Where is the source of this slowness, accessing JD TypedArrays is so much > slower than operating with C pointers and C++ STL containers? > > Thank you, > Boris > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to emscripten-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
