Can you reproduce the 20x slowdown and simple benchmark or something you can share?
cheers, sam On Mon, Apr 26, 2021 at 12:11 PM John R <[email protected]> wrote: > Hey thanks Floh and Sam for the responses! > > I thought setting the INITIAL_MEMORY would help as well, but it doesn't > seem to make a noticeable difference. The particular function that I'm > examining takes on average ~1ms on native and roughly ~20ms in the > browser...so, a 20x slowdown, which seems a little crazy (I've heard that > 3-4x slowdown is normal). > > I'm at a loss for what else to try here. For completeness, here is a list > of all of the flags I'm passing to emcc: > > * "--bind \* > * --profiling \ * > * -s MODULARIZE \* > * -s EXPORT_ES6 \* > * -s EXPORTED_FUNCTIONS=\"['_malloc', '_free']\" \* > * -s EXPORTED_RUNTIME_METHODS=\"['ccall']\" \* > * -s INITIAL_MEMORY=134217728 \* > * -s ALLOW_MEMORY_GROWTH=0 \* > * -O3 \* > * -v"* > > Any other thoughts or ideas for me to try would be greatly appreciated! > Thanks so much for all of your help so far. > > On Monday, April 26, 2021 at 7:26:47 AM UTC-7 Floh wrote: > >> I'm not sure how exactly memory-growth works these days (I'm sure it's >> much more efficient than in the olden days), but maybe your std::vectors >> are frequently bumping against the top of the WASM heap and cause heap >> regrowths (although one would expect that this only happens within a very >> short "warmup phase". >> >> Does it help if you increase INITIAL_MEMORY with the linker option "-s >> INITIAL_MEMORY=xxx"? >> >> (the default seems to be 16 MBytes: >> https://github.com/emscripten-core/emscripten/blob/897d6fac93c4152feb03dfbef6eec1e21af39ae1/src/settings.js#L170 >> ) >> >> >> On Saturday, 24 April 2021 at 01:00:33 UTC+2 [email protected] wrote: >> >>> Hi all, >>> >>> I have some C++ code (compiled to WASM) that I'm having >>> trouble optimizing. I've been profiling the code with Chrome DevTools, and >>> I've made sure to specify the *-O3* optimization flag. >>> >>> The slowest parts of the code seem to be related to allocating, >>> resizing, and destroying std::vector<T> instances. In my case, `T` is >>> always a basic numeric type, like float or int. Unfortunately, I don't have >>> much control over *how* these allocations / deletions happen, as >>> they are deep within the internals of a library I am using. >>> >>> Basically, there is a class that I'm using that allocates a bunch of >>> small vectors upon construction and destroys them upon deletion. The >>> constructor / destructor for this class are the parts that I'm noticing are >>> quite slow, and the vast majority of the call time seems to be spent on >>> resizing and/or destructing std::vector<T>. >>> >>> Short of rewriting this part of the code to use some sort of global >>> memory pool, rather than a bunch of small, independent allocations (not >>> even sure this would help - just a guess), is there anything else I can do >>> or should look into? >>> >>> I should note that I am using the *ALLOW_MEMORY_GROWTH* flag as well. >>> >>> Thanks, >>> John >>> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/898d50f3-d059-4692-8c31-63cafd249d58n%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/898d50f3-d059-4692-8c31-63cafd249d58n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_EG-g1usS7YX%2BgaL8H6A35uJLpnFRxVkxKQWPeKMf_gg%40mail.gmail.com.
