Slow std::vector behavior

175 views
Skip to first unread message

John R

unread,
Apr 23, 2021, 7:00:33 PM4/23/21
to emscripten-discuss
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

Sam Clegg

unread,
Apr 24, 2021, 12:57:18 AM4/24/21
to emscripte...@googlegroups.com
It would be interesting to know if you observe the same behaviour when running on native platforms.  I would expect the overhead of the allocator (new/delete/malloc/free) to be roughly the same for emscripten as for your native linux build.  If you are seeing the allocator overheads if emscripten differ significantly with emscripten compared to other targets then it would and issue worth investigating, bit if we are in the same ballpark then you this could just a be C/C++ optimization question, rather than an emscripten-specific issue.   It could also be a libc++ be libstdc++ issue of course (we use libc++ whereas most desktop linux distros using libstdc++).

cheers,
sam

--
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-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/e0a8a88a-481a-48fb-bff8-4ff5dc03f8e0n%40googlegroups.com.

Floh

unread,
Apr 26, 2021, 10:26:47 AM4/26/21
to emscripten-discuss
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"?

John R

unread,
Apr 26, 2021, 3:11:15 PM4/26/21
to emscripten-discuss
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.

Sam Clegg

unread,
Apr 26, 2021, 3:35:17 PM4/26/21
to emscripte...@googlegroups.com
 Can you reproduce the 20x slowdown and simple benchmark or something you can share?   

cheers,
sam

--
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-disc...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages