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.
